New answers tagged dependency-injection
2
Let's keep this pragmatic and simple:
The hexagonal architecture was laid down by Alistair Cockburn in a 2005 article. A single article (and a couple of talks) that let a lot of aspects unaddressed. Since then, it inspired a lot of people, such as Jeffrey Palermo with his Onion Architecture in 2008, Uncle Bob with his Clean Architecture in 2012, and more ...
0
Since the FileCreator class requires the StreamWriter in order to work correctly, that means that a FileCreator without a StreamWriter makes no sense, which in turn means that it should require the StreamWriter in its constructor. (Your [3] solution.) There are now a few problems left to solve:
The Dependency Inversion Principle states that "details should ...
0
When applying Uncle Bob’s clean architecture principles an interactor is a “use case request handler”.
In your example you have one use case, or feature as you call it. Therefore it makes sense to have a single interactor at this point.
At some point the requirements will change, for example the UI should display the ‘transfer funds’ button only if ...
0
Is the intent for clients to only see a single interface? If so, either way is “correct”. Typically, you’d start with one class and as the API starts expanding you could add more “internal” classes to handle specific methods or groups of methods (your second example).
If the amount of methods starts becoming excessive or the methods being added feel like ...
2
In the general case, if it wouldn't be about user input, the first approach is not necessarily bad:
You inject an object at construction,
You observe the injected object
And you react on the observed object's change of state
If done properly, you have the desired behavior, and loose coupling.
But in the context of your problem, this perfectly decent ...
2
The best option is to have two libraries.
One would be your library, which is IoC-agnostic. All classes use constructors for their dependencies. If there are any specific ways objects need to be created, the library provides abstractions that can be implemented by IoC code. As for your comment for "cannot use same composition root" I find that hard to ...
2
You should not be using any dependency injection containers when you are writing a library meant to be consumed by others. It may be acceptable if you know all the projects using the library and they all agree to use the same DI container. This might be the case with internal company libraries.
I find it extremely impolite to force a DI container on people ...
3
Passing the StreamWriter as a constructor argument to FileCreator is the preferred approach if the stream writer is indeed a shared resource between all method calls against any one particular FileCreator object.
If you need to specify different stream writers for different method invocations on FileCreator, then you need to pass the StreamWriter as an ...
Top 50 recent answers are included
