Tag Info

New answers tagged

2

You're going for something akin to (but not similar) Spring's ApplicationContextAware, where you pass ApplicationContext (which is a BeanFactory) via a setter, so it later can get beans it needs. Generally it is a bad idea, if you only need to inject dependencies: It is not explicit about dependencies it uses. So, it is actually harder to mock, not ...


3

Your dependency lookup looks very similar to service locator pattern, except that often, service locator is static. The benefits of such dependency lookup when compared to ordinary dependency injection are that: You won't find constructors which take dozens of (often mandatory) arguments if they need many dependencies. This makes your code shorter and ...


2

The obvious, albeit obnoxious answer, would of course be "it depends"... ;) Most of the resolvers in the "major" IoC containers out there allow you to specify this when defining the resolution schema. In Castle Windsor, for instance, you can define the lifetime as Singleton, Transient, Bound, Thread, ... (there is a bunch). Your example is a pretty clear ...


4

If you do not apply DI as long as you do not really need it (not even for unit testing), nothing bad will happen. The code does not become error prone, "overly complicated", or hard to maintain. And if you decide to refactor the dependency out later, it will most probably not be much more effort than doing it now. That's a case where the YAGNI principle ...


7

There's a development principle along the lines of DRY and SOLID called YAGNI that is designed to help streamline your development efforts in getting things done and not getting paralysed with indecision over what to do. If you later find that you need to enhance your class, then you will. YAGNI says not to worry so much over it now 'cos you probably won't ...


0

The answer like most things is "it depends". If you want to unit-test the functionality in doSomethingImportantUsingDependency, then you will need to be able to inject the dependency. However, if all that doSomethingImportantUsingDependency does is some property mapping from the result of your database call, then it would be pragmatic to not bother. If ...


9

In C# it is trivial to provide optional dependency injection without coupling yourself to your dependency too tightly: public class SomeOtherClass { private readonly ISomeClass _someClass; public SomeOtherClass(ISomeClass dependency = null) { _someClass = dependency ?? new SomeClass(); } } (or you can make the constructors explicit if ...


3

I would do this: For every class that implements IContextMenu create a Factory/Creator. For example for a class named TypeAContextMenu create a TypeAContextMenuCreator, for TypeBContextMenu create a TypeBContextMenuCreator, etc. Every creator implements the same interface, like say IContextMenuCreator, they just have a create() method that returns an ...


4

As an outsider looking at this code, it is not clear how the "hidden dependencies" get created to begin with. What if there is no "db" dependency registered? Does it throw an exception, return null? If my class doesn't get a "db" dependency, how bad is that? Many times people lean towards this pattern when there are too many dependencies to pass in the ...


1

if any of the methods fails, there is really no point in calling subsequent methods. How should I address those possible method failures? Throw an exception. Should the Carousel class be 'injected' into my class before it is used? Yes, if there is more than one implementation of Carousel (including the possibility of a mock object for unit testing ...


3

An Item-Class is there to tell you about data relating to items, and perform business logic that is centered around them - so making it able to tell you its price for a given customer and quantity, its main-image-filename or some such doesn't seem like a violation of the Single Responsibility Principle. Yes it is a violation of the SRP. It is ...


8

I would go with the anemic domain model here. Consider the example of your ItemImageFinder. Consider a few scenarios: You decide to extend your system to also include Image thumbnails, or including alternate images. Now you need to modify your Item behavior. Clearly this is not the only reason for Item to change, so you are violating SRP. You either have ...



Top 50 recent answers are included