Tag Info

Hot answers tagged

39

So, what am I missing? Dependency Injection decreases coupling between a class and its dependency. But it increases the coupling between a class and its consumer (since the consumer needs more info to create it) and the dependency and its consumer (since the consumer needs to know the dependency to use). Very often, this is a good trade off. The class ...


31

The approach your professor proposes is best described as stringly typed and is wrong on almost every level. Coupling is best reduced by dependency inversion, which does so by a polymorphic dispatch, rather than hardwiring a number of cases.


31

In theory, loose function-data coupling makes it easier to add more functions to work on the same data. The down side is it makes it more difficult to change the data structure itself, which is why in practice, well-designed functional code and well-designed OOP code have very similar levels of coupling. Take a directed acyclic graph (DAG) as an example ...


23

In layman's words: Not all users use all of a company's apps Different users have different needs Why force an user to buy a full package when he/she needs only a part ? (Ok, Google apps are free, but other software maker's aren't.) Having those apps separate makes it possible to be updated separately and, most importantly, sold separately. The fact that ...


21

Suppose you have a subsystem S that depends on a database connection D. Without dependency injection, there is a relatively tight coupling between S and D, because S needs to know both how to use D and how to create it. The rest of the system, however, can be blissfully unaware of this dependency between S and D. With dependency injection, the coupling ...


16

Your professor is doing it wrong. He's trying to completely decouple the view and model by forcing communication to travel via string in both directions (view doesn't depend on model and model doesn't depend on view), which totally defeats the purpose of object-oriented design and MVC. It sounds like instead of writing classes and designing an OO-based ...


14

Well, your first three points are actually about other principles than coupling. You always have to strike a balance between oft-conflicting design principles. Your fourth point is about coupling, and I strongly agree with you. Coupling is about the flow of data between modules. The type of the container that data flows in is largely immaterial. Passing ...


12

There is a balance that needs to be achieved between looseness of coupling and complexity. As the person responsible for the overall architecture, you need to strike that balance. When we call a ToString() method on an object, we can do so safely because we know all of our classes derive from a base class that has a ToString() method, and that method can ...


11

ENUMs (or final Strings if you are old school ,programming mobile...) should be used instead of magic Strings. Your professor doesn't understand OO. For example having a concrete Vehicle class? And to have this class understand the make of a bicycle? Vehicle should be abstract and there should be an concrete subclass called Bike. I would play by his rules ...


11

In case you didn't know it already take this insight: The concepts of object-oriented and closures are two sides of the same coin. That said, what is a closure? It takes variable(s) or data from surrounding scope and binds to it inside the function, or from an OO-perspective you effectively do the same thing when you, for example, pass something into a ...


11

I've been involved in projects like this twice now (both using nuget with .NET), and I would say that on balance it is a good idea. But your mileage may vary. Don't think for a minute that it's a panacea, that it's going to solve all of your problems without causing new ones. Release management will gain a whole new layer of complexity, you'll need to deal ...


10

My recommendation is: Use addTrack( ITrack t ) but be sure that ITrack is an interface and not a concrete class. Album doesn't know the internals of ITrack implementors. It's only coupled to the contract defined by the ITrack. I think this is the solution that generates the less ammount of coupling.


9

TO make your code loosely coupled here are a few simple things to remember: Part 1: Technically known as "Separation of Concern". Each class has a specific role, it should be handling business logic or application logic. Try and steer clear of class that combine both responsibilities. i.e. A class that manages (broad term) data is application logic while a ...


9

If you really need coordination between those two classes, write a CsvCoordinator class that encapsulates your two classes, and test that. However, I dispute the notion that CsvRecord is not independently testable. CsvRecord is basically a DTO class, is it not? It's just a collection of fields, with maybe a couple of helper methods. And CsvRecord can be ...


8

Good question, simply put, decouple. That's the way to go here, you do not want to be tied to the version of java. There's one scenario you don't decouple: if your technology will allow for non-type-specific objects to be sent over the wire, that is, if you can use the current java objects now as a YAGNI, and the replacement with a different type that you ...


7

From the comments I see you're using Java. Have a look at various Queue implementations. Particularly, BlockingQueue is useful for producer-consumer scenarios. You could have two queues: one between Source (producer of data) and Process (consumer of data), and another between Process (producer of results) and Persist (consumer of results). With ...


7

Constants that are specific to a class should go in that class's interface. Constants that are really configuration options should be part of a configuration class. If you provide accessors for the configuration options in that class (and use them in place of the constants elsewhere), you won't have to recompile the whole world when you change a few ...


7

I strongly disagree that it increases coupling. Without dependency injection you have tight coupling between a sub system and the concrete implementation of the dependency. With dependency injection you have decoupled the sub system from the implementation of the dependency. Making the argument that it increases coupling between the consumer and this sub ...


6

I think you have a good point, the magic strings are bad. Someone on my team had to debug a problem caused by magic strings a couple weeks ago (but it was in their own code that they wrote so I kept my mouth shut). And it happened... in industry!! The advantage to his approach is that it might be faster to code, especially for small demo projects. ...


6

I would say it's definitely not as bad as a God Object or Super Object. Those are a whole different animal that is hard to write, maintain, debug, and test and they should be avoided at all costs. As far as the namespace goes, that's definitely a legitimate concern, and if you are finally getting to the point where your namespace is becoming overcrowded I ...


6

As far as I can tell, your example closely matches the strong coupling, as it is defined in Wikipedia: Strong coupling occurs when a dependent class contains a pointer directly to a concrete class which provides the required behavior. The dependency cannot be substituted, or its "signature" changed, without requiring a change to the dependent class. ...


6

I know you're trying to simplify your scenario to make it easier to discuss, but why does the OrderItem care about the Header? The Header is Aggregator (called the "Root" in DDD) and it is responsible for knowing about its components (OrderItem being one of them). If you're discussing special cases like Discounts being applied to Orders containing for ...


6

The main arguments for #1 are ease of implementation and upgrades, but does it satisfy your requirements? In your arguments for #2, you indicate that the Java API and REST API may likely change independently. This means they are separate concerns and you are not repeating yourself by using separate classes. Just because two things look the same, doesn't ...


6

Users expect a mobile app to perform a single task, or a small set of very related tasks. The mobile platforms that you mention started particularly as phone OS's. Typically users performs many short tasks on their smartphone throughout the day. This is totally different from desktop computers. This short bursted usage pattern has lead to the design of a ...


5

Using 'industry experience' is a poor argument. Your professor needs to come up with a better argument than that :-). As others have stated, the use of magic Strings is certainly frowned upon, using enums is considered far safer. An enum has meaning and scope, magic strings do not. Aside from that, the manner in which your professor is decoupling concerns ...


5

I would say it is a Temporary Field. The context is created outside of the method where it is needed and stored as a field. Sometimes you see an object in which an instance variable is set only in certain circumstances. Such code is difficult to understand, because you expect an object to need all of its variables. Trying to understand why a variable is ...


5

You're describing a layer relationship more than a coupled relationship. Unless your BusinessLogic depends on and makes calls into AppInterface, it's not coupled. Having a lot of dependencies on the layer below you is quite natural and unavoidable. You don't worry about how much your BusinessLogic depends on a database layer, do you? However, the fact ...


5

I'm a ASP.NET developer so don't know much about WinForms coupling, but know a little from N-Tier web apps, assuming a 3 tier application architecture of UI, Domain, Data Access Layer (DAL). Loose coupling is about abstractions. As @MKO states if you can replace an assembly with another (e.g. a new UI project that uses your Domain project, a new DAL that ...


5

Do the classes really need to be decoupled? In your example, from business point of view, the order header and order item are entities, that are really close. They probably form an aggregate. So trying to decouple those will create unnecessary complexity and will make reading the model confusing. To solve this, I would try to locate aggregates in your code ...


5

It's about type coupling: A function built into an object to work on that object can't be used on other types of objects. In Haskell you write functions to work against type classes - so there are many different types of objects any given function can work against, so long as it's a type of the given class that function works on. Free-standing functions ...



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