New answers tagged

1

I think the question is a symptom, not a solution. I recently read a lot about Singletons being bad and how dependency injection (which I understand as "using interfaces") is better. When I implemented part of this with callbacks/interfaces/DI and adhering to the interface segregation principle, I ended up with quite a mess. A solution looking for a ...


9

Should composition happen no matter what? No. If that's a good enough answer for you, you don't need to read the rest. As with everything in programming, you shouldn't use a programming approach just because someone mentioned it somewhere and said an apple is better than a beef steak. Yes, a beef steak might be better for your taste buds if you ...


3

Are there any other objections? Are there any legitimate, real-world reasons why DI with a static/global service locator would be bad? Ugh, yes. Statics/globals are horrible. They assume that the runtime of your application is homogenous - all of your instances require all the same sort of instances all over. That is naive. They interfere with ...


1

I think you are missing the benefit of dependency injection--that anything the class depends on is given to it, rather than assumed. What you're proposing is the service locator anti-pattern. There are a few cases where I might be tempted to use it (identity), but I'd prefer a clean contract for one reason--I never know how someone is going to use my code. ...


1

"Class heirarchy" is a bit of a red flag. Hypothetical: a web page with 5 widgets. The page is not an ancestor of any of the widgets. It may hold a reference to those widgets. But it is not an ancestor. Instead of class heirarchy, consider using composition. Each of the 5 widgets can be constructed on its own, without reference to the other widgets or ...


1

Let's just assume for a minute that it is perfectly fine to skip DI with sknny controllers. Now what about the rest of your application? Dependency Injection as a technique is proven to be immensely useful and valuable. As others have noted, it encourages a more decoupled design which improves testability. These are extremely valuable perks! MVC or no ...


3

Dependency injection is often recommended in MVC projects because it's easy to implement with the pattern and adds a host of potential benefits I would argue that dependency injection is recommended generally in projects (not just MVC) because of the benefits it brings in terms of decoupling and testability. There's nothing specific to an MVC ...


1

Yes there is value because it allows you to unit test your controllers. The business layer and model should know nothing about http so the job of the controller is translating the business layer to a web world. Example: Exception Y was thrown should result in http status 4xx Precondition A was not met. Redirect to Abc So even if the controller is ...


1

I'm more used to seeing dependency injection working in terms of the instantiated objects, rather than the factories (unless the components that you inject into need to create these objects dynamically post-wiring) e.g. I would use the factories to instantiate the components up front, and then wire them together e.g (in pseudo-Scala, but the intent should ...


2

I'd really be more worried about the fact that you seem to feel the need to "mock" just about every type in your whole project. Test doubles are mostly useful for isolating your code from the external world (third-party libs, disk IO, network IO, etc.) or from really expensive computations. Being too liberal with your isolation framework (do you even REALLY ...


0

Should I instantiate value & collection objects with factories [..]. No, usually creation of value objects is very simple and there is no need for factories. At most you will use some kind of static constructor, like Money::fromString() which will instantiate value object and needed dependencies. [..] and injected dependencies or should I ...



Top 50 recent answers are included