Tag Info

New answers tagged

0

The general rule in complicated programs is Separation of Data and Control The more that you can keep these two aspects separate, the easier the software will be to maintain. This what you are trying to do in your refactoring. I would suggest that you take a more drastic step and use a "business rules engine" to drive your program. I don't mean one of ...


2

If you have too many dependencies being passed around, the general technique is to eliminate those dependencies higher up in the call stack, by changing the order decisions are made. This is easiest to explain with an example: getPath(config, user) { if (config.isB2B()) return b2bpath(config, user); else return b2cpath(config, user); } ...


2

One reason for introducing a separate variable is to improve readability, assumed the real name of $someClass->thisVar() is not expressive enough. This can make sense even if the function is only called once: function someFunction(SomeClass $someClass) { $explainingName = $someClass->thisVar(); doSomethingElse($explainingName); } Of course, ...


0

There is a DI framework for C++ (still under development AFAIK): Boost.DI. There are some useful comments about the framework on reddit.


3

It depends on the current situation and the size of the project. Registering the classes that implement this interface in the IoC container and then injecting specific implementations in the objects that depend on the interface might be the way to go in some cases but might be an overkill in others. In small projects, I prefer the benefits of seeing ...


5

The best arguments against the Service Locator anti-pattern are plainly stated by Mark Seemann so I won't go too much into why this is a bad idea - it is a learning journey that you have to take the time to understand for yourself (I also recommend Mark's book). OK so to answer the question - let's re-state your actual problem: So rather than adding ...


-1

I am adding an answer to this based on everybody else's contributions. So many thanks everbody. First here's my answer: "No, there's nothing wrong with it". Doc Brown's "Service Facade" answer I accepted this answer because what I was looking for (if the answer was "no") was some examples or some expansion upon what I was doing. He provided this in ...


1

You're giving up a lot of static information this way. You're deferring decisions to runtime like many dynamic languages do. That way you loose static verification (safety), documentation and tooling support (auto-complete, refactorings, find usages, data flow). A classic static/dynamic trade-off. I would not do it this way. I don't see why adding ...


2

Having one instead of many parameters in the constructor is not the problematic part of this design. As long as your IContext class is nothing but a service facade, specificially for providing the dependencies used in MyControllerBase, and not a general service locator used throughout your whole code, that part of your code is IMHO ok. Your first example ...


15

This design is known as Service Locator* and I don't like it. There are lots of arguments against it: Service Locator couples you to your container. Using regular dependency injection (where the constructor spells out the dependencies explicitly) you can straightforwardly replace your container with a different one, or go back to new-expressions. With your ...



Top 50 recent answers are included