New answers tagged

0

I think this is a great idea partly because I had exactly the same idea myself. I know it is workable at least because I've done something very similar. I'd be very interested to see what other objections are raised. As to the ones so far, I don't think they are substantial. The most interesting is within the ...


1

Use a powerful service locator, which is, as Martin Fowler will tell you, nearly functionally equivalent to DI. Then set the service to whatever mock you like for the duration of the test in the context in which the test is running. e.g. (C# code, sorry) public class Service() { public void Foo() { ... IDependency dependency = ...


3

If you donot like the additional constructor arguments for the dependencies you need a DI-Container to handle the instance creation for you. You can use either an existing di-container framework or implement a poor mans version on your own public PoorMansDiContainer : IPoorMansDiContainer { private IService mService = null; private IFooService ...


8

The essence is simply that given an object, you pass its dependencies to it rather than let it instantiate them itself. How you achieve that, by containers, configuration, or any other means, is up to you.


1

MEF it. Built into the .NET framework is an often looked over namespace, created primarily for handling plugin support: System.ComponentModel.Composition - also known as MEF. MEF can be applied very effectively for DI, possibly providing exactly what you're looking for. First, you decorate a class with the needed attributes: [Export] // This attribute ...


4

so I'd enjoy seeing the different categories of dependencies registered together. Ninject provides the concept of a module to allow you to group related bindings into a single class. https://github.com/ninject/Ninject/wiki/Modules-and-the-Kernel class WeaponsModule : NinjectModule { private readonly bool useMeleeWeapons; public ...


0

This is what I've come up with based on the response already from @Robert Harvey which will work for at least 90% of the use cases that I will need. This will declutter the Registration process for sure. The configuration of whether to register a type, and the lifetime of the objects created are controlled from the class/interface files and not the ...


2

The way that we solve this problem where I work is by binding interfaces through reflection. Each class is decorated with an attribute that specifies which interface contract the class fulfills. When the application loads, our DI container (called a "Creator") reflects over the entire assembly and stores all of these interface/type pairs in a dictionary. ...


1

In my experience, a dependency injection framework leads to a number of issues. Some of the issues will depend on the framework and tooling. There might be practices that mitigate the issues. But these are the issues that I've hit. Non-global objects In some cases, you want to inject a global object: an object which will have only one instance in your ...


2

First Cross cutting concerns are not major building blocks and shouldn't be treated as dependencies in a system. A system should work if e.g. Logger is not initialized or cache is not working. How will you make system less coupled and cohesive? That's where SOLID comes into picture in OO system design. Keeping object as singleton has nothing to do with ...


0

Yes, when working in Java, I would recommend a DI framework. There are a few reasons for this: Java has several extremely good DI packages that offer automated dependency injection and also usually come packaged with additional capabilities that are harder to write manually than simple DI (eg scoped dependencies that allow automatic connection between ...


1

Does Java + dependency injection = framework required? No. What does a DI framework buy me? Object construction happening in a language that isn't Java. If factory methods are good enough for your needs you can do DI in java completely framework free in 100% authentic pojo java. If your needs go beyond that you have other options. The Gang of Four ...


4

The point of DI frameworks is that they do abstract this part of the design. This has a noticeable impact on the code. Less constructors and less components like Factories or Builders, so part of the code becomes much simpler. DI is oriented to declarative programming. It basically means that DI is going to be defined by files (xml, properties, ...) or by ...


1

Yes. You should probably read Mark Seemann's book titled "Dependency Injection". He outlines some good practices. Based on some of what you've said, you might benefit from. You should aim to have one composition root or one composition root per unit of work (e.g., web request). I like his way of thinking that any object you create is considered a ...


0

Creating classes and assigning them dependencies is part of the modeling process, the fun parts. It's the reason why most of programmers enjoy programming. Deciding, which implementation will be used and how classes are constructed is a thing which will have to be implemented somehow and is part of application configuration. Manually writing factories is a ...


3

Yes and No, but mostly No I assume most of the conversation is based on static vs injected instance. No one is proposing that logging break the SRP I assume? We're mainly talking about the "Dependency inversion principle". Tbh I mostly agree with Telastyn's no answer. When is it okay to use statics? Because clearly it is sometimes okay. The yes answers ...


4

Logging genuinely is a special case. @Telastyn writes: Are you really never going to change your logging library, or target, or filtering, or formatting, or...? If you anticipate that you might need to change your logging library, then you should be using a facade; i.e. SLF4J if you are in the Java world. As for the rest, a decent logging library ...


3

First it starts with strong singleton cache, the next things you see are strong singletons for database layer introducing global state, non-descriptive APIs of classes and untestable code. If you decide not to have a singleton for a database, it's probably not a good idea having a singleton for a cache, after all, they represent a very similar concept, data ...


10

My 2 cents ... Yes and no. You should never really violate the principles you adopt; but, your principles should always be nuanced and adopted in service to a higher goal. So, with a properly conditioned understanding, some apparent violations may not be actual violations of the "spirit" or "body of principles as a whole." The SOLID principles in ...


3

Yes and No! Yes: I think it is reasonable that different subsystems (or semantic layers or libraries or other notions of modular bundling) each accept (the same or) potentially different logger during their initialization rather than all subsystems relying the same common shared singleton. However, No: it is at the same time unreasonable to parameterize ...


33

Yes This is the whole point of the term "cross-cutting concern" - it means something that does not fit neatly in the SOLID principle. This is where idealism meets up with reality. People semi-new to SOLID and cross-cutting often run into this mental challenge. It's OK, don't freak out. Strive to put everything into terms of SOLID, but there are a few ...


2

I've solved this problem using a combination of inheritance and traits (also called mixins in some languages). Traits are super handy for solving this kind of cross cutting concern. It's usually a language feature though so I think the real answer is that it's dependent on language features.


39

No. SOLID exists as guidelines to account for inevitable change. Are you really never going to change your logging library, or target, or filtering, or formatting, or...? Are you really not going to change your caching library, or target, or strategy, or scoping, or...? Of course you are. At the very least, you're going to want to mock these things in a ...


8

The idea that logging should always be implemented as a singleton is one of those lies that has been told so often it has gained traction. For as long as modern operating systems have been about it has been recognised that you may wish to log to multiple places depending on the nature of the output. System designers should constantly be questioning the ...


24

For logging I think it is. Logging is pervasive and generally unrelated to the service functionality. It's common and well-understood to use the logging framework singleton patterns. If you don't, you're creating and injecting loggers everywhere and you don't want that. One issue from the above is that someone will say 'but how can I test logging?'. My ...


2

Thus, most of them have just one method. This looks smelly even in statically checked, object oriented languages such as Java or C# which don't discourage creating more and more interfaces and classes. In languages such as PHP, Ruby or Python, this looks even wronger. An interface and two classes for just a string? Seems like too much architecture and ...


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 ...


4

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. ...



Top 50 recent answers are included