Hot answers tagged

22

High coupling is bad, low coupling good. I won't put it so black and white. Some coupling is necessary. Plus some roundabout ways to get rid of coupling can introduce too much overhead. In particular for applications that need to respond in real time. It is trade-offs. Yes, you want to avoid high coupling. However, if introducing patterns in an attempt to ...


10

And one change in B would have an impact in IB and A. This is not correct. A change to its signature would impact IB and A, but changing its implementation would not. You could change your underlying data store, or the algorithm used to do the operation, or add in some extra logging - all without impacting A. In this case, it looks like we transferred ...


6

You are absolutely correct that introducing an interface or a facade does not in itself reduce coupling. Introducing an interface can be used to reduce coupling in a few ways. If multiple classes implement the same interface, then the caller is decoupled from any specifics of the classes. But if the interface is only implemented by a single class, then you ...


5

Add method Print to the interface Cats will implement this method by printing out some value Birds will implement it as an "empty" method, which do nothing or print empty string. public interface IAnimal { public string Name { get; } public void Print(); } public class Cat : IAnimal { public Cat(string name) => Name = name; public ...


4

You cannot remove required coupling. If you need to call .read() to read from a file, and .close() when you finish, you will continue to do so. But consider other changes to class File. If anything at all changes in its implementation, you have to recompile any code that uses File, because the compiler has to make sure that anywhere a File instance is ...


3

This doesn't occur to a lot of people for some reason, but my preferred way in real code is to never mix them up in the first place. Have a List<Bird> and a separate List<Cat>, and either create your List<Animal> from the first two on demand when needed, or add to it at the same time you construct the bird and cat lists. The other ways I'...


2

For long running tasks, blocking in order to return the response synchronously is not appropriate. What you should do instead is have your service accept the request, start the long running job, and return a success response. Here's a basic design for this kind of thing: The client submits uses POST to send a request that starts the job. You then return ...


2

It's easy to learn the wrong lesson here so bear with me a moment. There is a good reason you look at this code and expect it to print "yes". It's called semantics. You are looking at the way things are named and trusting the names to tell you the intent of the code. This is a very good instinct and you shouldn't lose it. Even though, right now it seems to ...


1

From my more practical view point (I get paid to make things work), Java is doing this absolutely correctly. Objective-C is the same. Of course they both have a decent default implementation. So what doesn’t make sense to you makes perfect sense to me. Swift had a bit more time and refined this somewhat. Not any object needs a hash code, and hash codes are ...


1

The recommended solution is to return 202 Accepted (http status for saying request has been accepted for processing but processing is not complete) Then notify the user upon completion of the request. WebSocket is a popular mechanism to accomplish this. It is not recommended for user facing operations to take more than a second, even if the user is aware ...


Only top voted, non community-wiki answers of a minimum length are eligible