This is from chapter 14 of the book "Clean Architecture"
It's trying to break the direct dependency of Stable-->Flexible by introducing UServer.
So that we can have Stable-->UServer<--Flexible where nobody would depend directly on the concrete class c.
But in figure 14.11, who will instantiate c?
It can not be Stable, that will introduce Stable-->Flexible back.
It can not be UServer, that will give you bi-directional dependency.
It can not be Flexible itself, because that will still force Stable to call Flexible.
So it has to be something that not in figure 14.11, right? Like some sort of dependency injection framework?
Is the author implicitly expressing that?
What you are looking for is the "Main Component". According to Uncle Bob this is the place where all the "ugly details" go to, where all the wiring and dependency injection goes to. See chapter 26
Related
I've been learning Go for a class course and I am very excited with the language, it really is very useful for web services.
So, I've been writing this CRUD restful API for a final project and I keep running in the damn circular dependency problem. I've already researched and read on the ways of solving it and will post here just for the sake of it, but first the problem I am having:
routes need to know about the handler functions in the handlers package, which in turn need to know about the user structure inside the model package, which in order to send a registration e-mail with a link need to know about the routes path
Classical A -> B -> C -> A
Now, I am trying to write this API using MVC and three layer architecture, this I would love for my routes to be in a controller package, my handlers to be on a business logic package and my user on a model package. This is also needed because I have over 43 model classes, I need them tidy up and tucked away on their package.
Ok, the solutions I found out
1 - Throw everybody on the same package : That's what I've been doing so far but is a very horrible solution for obvious reasons.
2- Pass whatever user needs as argument when it's functions are called: That would be a good solution, but won't work because the function that is being called from user is from an interface implementation because it has to be a generic call and before anyone goes around saying that my problem is because I am forcing generics in go, well too bad, I need that generic, I will not write over 160 crud functions. The whole point of functions is to avoid code repetition.
3- Create another package, with another interface, and have it having a instance of handlers and user and have it pass arguments from one to the other: Despite the reason mentioned above, the need of generic, this sounds like an unnecessarily complicated solution, I refuse to believe that this is better design than circular dependencies.
Bottom line question: How to solve this dependency when C needs to know information from A and generics must be respected
I can post some code here if you need to but I don't see the relevance of specific code when this is more of a high level question.
EDIT: Solved my dependency problem. Thank you all for the comments and answer as it led me to the answer. I don't think I've implemented any of the solutions suggested but it did taught me a lot about how to solve the problem, and they would all be very acceptable and doable solution if it wasn't for my own constrains where I don't want to pass anything to User.
To anyone trying to solve their own dependency problem, what I was able to gather is, instead of making in my case, C ask something from A, give to C whatever it needs, before it has to ask, meaning pass the information to him.
Alas, that was not my solution, what I did was remove the information from A and give the information to Z, now both A and C are asking the path information to Z, which is just a Map, sitting there being all map like and holding information.
Thank you all
You've got some options, and you've found some of them. The main ways of handling this are:
Refactor your design to turn the cycle into a tree. This doesn't really apply to your situation due to your requirements.
Refactor your design to use some kind of dependency injection (this is your 2nd option in your question). This is perfectly viable, and probably the cleanest and easiest.
Refactor your design to take a locally declared interface. This is a more Go-idiomatic version of your option 3. Because interfaces in Go are duck-typed, you get to define it where it's consumed, rather than where it's implemented. So your user package can define a one-method interface for "a thing that gives me a URL I need" and it never needs to reference the package that implements the interface.
I'm starting to develop website that use the spring framework.I have three controller.There are newCustomerController,editCustomerController and deleteCustomerController.These controllers are mapped with view that use for create update and delete, but I create only customer.
So, I would like to know.Is it appropriate to declare the controllers like this.
Thank
The answer to this question is subjective and maybe more a topic for https://softwareengineering.stackexchange.com/. However, there is something very spring related about it that I would like to comment.
There are a few principles that attempt at guiding developers of how to strike a good balance when thinking about designing the classes. One of those is the Single responsibility principle.
In object-oriented programming, the single responsibility principle
states that every class should have a single responsibility, and that
responsibility should be entirely encapsulated by the class. All its
services should be narrowly aligned with that responsibility
A catchier explanation is
A class or module should have one, and only one, reason to change.
However, its still often hard to reason about it properly.
Nevertheless, Spring gives you means for it (think of this statement as a poetic freedom of interpretation). Embrace constructor based dependency injection. There are quite a few reasons why you should consider constructor based dependency injection, but the part relevent to your question is adressed in the quote from the blog
An often faced argument I get is: “Constructors just get too verbose
if I have 6 or 7 dependencies. With fields only, this is fine”.
Awesome, you’ve effectively worked around a clear indicator that the
code you write is doing way too much. An increase in the number of
dependencies a type has should hurt, as it makes you think about
whether you should split up the component into multiple ones.
In other words, if you stick to constructor based injection, and your constructor turns a bit ugly, the class is most likely doing too much and you should consider redesigning.
The same works the other way around, if your operations are a part of the logical whole (like CRUD operations), and they use the same dependencies (now "measurable" by the count and the type of the injected deps) with no clear ideas of what can cause the operations to evolve independently of each other, than no reason to split to separate classes/components.
It should be better if you define one controller for Customer class and in that class you should have all methods related to customer operations (edit,delete,create and read).
I am starting an application that I would like to build quickly and will be later developed by 20+ developers.
Knowing what you know about DI in an environment with multiple developers, would you go with DI for a new application you'd like to build relatively fast?
The costs of using DI to me right now, would be lines of code written and generated vs not using an interface for every object. And down the line I am hoping DI doesn't become a performance problem because of reflection.
DI is basically not about frameworks. If you just add your dependencies, for example, as parameters to the constrictor, then you're doing DI. Actually you don't even need to create interfaces (though that would help testing. Introduce interface later is a simple refactoring in languages like Java). DI just removes the responsibility of creation from the user of the class.
The single greatest cost in my head would be change of mind. To learn to think DI.
benefits include easier testing. Separation of concern and more.
Simply said, doing Object-oriented development without dependency injection is bad. Very bad. Dependency injection is in my opinion the root of well-understood OO development: separation of concerns, loose coupling between independent components, coding in layers, all of that is done using DI. And also, it makes testing incredibly easier, and allows techniques like TDD, mocking (BDD), etc.
As Shakyamuni said in his answer, DI is not about the framework you use. Spring did not invent DI, it just proposes a solution to achieve it. So if your original question is "should we use Spring", then I'd say it's a question of personal taste. You can achieve exactly the same result if you do it yourself. I've worked in project with or without containers (Spring, pico, etc.) and they all have their benefits and drawbacks. My personal preference, though, is not to use any of it and manage your DI yourself.
This is DI:
// constructor
public MyClass(MyDependencyInterface injected) {
this.dependency = injected;
}
or that:
// setter injection
public void setDependency(MyDependencyInterface injected) {
this.dependency = injected;
}
And down the line I am hoping DI doesn't become a performance problem because of reflection.
No idea what you mean by that. DI does not require reflection.
I would definitely advocate DI, particularly when there are a lot of developers.
This allows each developer to write and test their own code without relying on injected components being developed outside of their control.
It can also facilitate interface definitions so everyone knows what functionality is available from which components.
The basic problem in Java is that when you in class A do a new B() this mean that class A is very tightly bound to class B at the byte code level.
This is typically a good thing as it means that the resulting application becomes very sturdy as all the "bricks" are very well "glued together".
You frequently, however, need to postpone some design issues to deploy time (and occasionally even runtime) and the way to handle this in Java has traditionally been to delegate to a Factory which perhaps even in turn delegates to another factory etc, until you reach the place where you make the decision. This is typically done with a property file containing either flags corresponding to if-statements in the code (which requires the programmer to foresee all situations when writing the code), or class names to resolve with Class.forName() (which is brittle as the compiler cannot help).
The advantage of Dependency Injection is that you sidestep the hard binding of the newoperator by delegating the responsibility to create an appropriate object outside of your own code (to a container but could as well be a deity). You create some very clear cut-lines where you can put things together and for those DI-frameworks providing code configuration (like Guice) the result can be as sturdy as well as modular.
Note that coding to interfaces makes it easier to identify the right places to make incisions for the cut-lines, because interface usages usually corresponds to injection points.
Warning acronym overload approaching!!! I'm doing TDD and DDD with an MVP passive view pattern and DI. I'm finding myself adding dependency after dependency to the constructor of my presenter class as I write each new test. Most are domain objects. I'm using factories for dependency injection though I will likely be moving to an IoC container eventually.
When using constructor injection (as apposed to property injection) its easy to see where your dependencies are. A large number of dependencies is usually an indicator that a class has too much responsibility but in the case of a presenter, I fail to see how to avoid this.
I've thought of wrapping all the domain objects into a single "Domain" class which would act as a middle man but I have this gut feeling that I'd only be moving the problem instead of fixing it.
Am I missing something or is this unavoidable?
Often a large number of arguments to a method (constructor, function, etc) is a code smell. It can be hard to understand what all the arguments are. This is especially the case if you have large numbers of arguments of the same type. It is very easy for them to get confused which can introduce subtle bugs.
The refactoring is called "Introduce Parameter Object". Whether that's really a domain object or not, it is basically a data transfer object that minimizes the number of parameters passed to a method and gives them a bit more context.
I only use DI on the Constructor if I need something to be there from the start. Otherwise I use properties and have lazy loading for the other items. For TDD/DI as long as you can inject the item when you need it you don't need to add it to your constructor.
I recommend always following the Law of Demeter and not following the DI myth of everything needs to be in the constructor. Misko Hevery (Agile Coach at Google) describes it well on his blog http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/
Having a Layer Supertype might not be a bad idea, but I think your code smell might be indicating something else. Geofflane mentioned the refactor pattern, Introduce Parameter Object. While it's a good pattern for this sort of problem, I'm not entirely sure it's the way to go for this situation.
Question: Why are you passing in Domain Model objects to the constructor?
There is such a thing as having too much abstraction. If there's one solid layer of code you should be able to trust, it's your Domain Model. You don't need to reference 3 IEntity objects when you're dealing with Customer, Vendor, and Product classes if those are part of your basic Domain Model and you don't necessarily need polymorphism.
My advice: Pass in application and domain services. Trust your Domain Model.
EDIT:
Re-reading the problem when it's not horribly late at night, I realize your "Domain class" is already the Introduce Parameter Object refactoring and not, in fact, a Layer Supertype, as I thought at 3AM.
I also realize that perhaps you need to reference the Model objects in the application code, outside the Presenter. Perhaps you're doing some initial setup of your Model objects before passing them in to the Presenter. If this is the case, your "Domain class" idea might be best. If there is some initial setup, when moving to an IoC, you'll want to look at something like Factory Support in Castle Windsor. (Other IoC containers have similar concepts.)
I have been wondering if the Factory Pattern and the Repository Pattern is keened to go hand in hand in a Domain Driven Design project?
The reason i ask is the way i'm doing this is like so:
GUI -> ClassFactory -> ClassProduct (is in the Domain Model) -> ClassProductRepository -> Datasource
The GUI calls the ClassFactory to separate the GUI from business logic. The ClassProduct calls the ClassProductRepository to separate the business logic from the datasource.
Is this a wrong approach of using these Design Patterns with Domain Driven Design? If so, please state your opinion on this subject.
Your on the right track. As Chad pointed out, you'll want to use a GUI interface separation pattern as an additional layer between your domain and the UI. MVC, MVP, Presentation Model, etc are established and well documented patterns for UI separation. Martin Fowler's excellent PoEAA covers many of them
As for your main question. Yes. Factories and Repositories work very well together. In fact, Evans suggests in DDD that in some cases you can delegate responsibility for object creation from your repository to your factory classes when you're reconstructing objects from the data store.
client <=> repository -> factory
|
v
database
The client requests an object from
the repository.
The repository queries the database.
The repository sends raw data to the
factory.
The factory returns object.
An over simplification but you get the idea. One point that isn't touched on by Evans (but which Fowler covers) is dependency injection. As your domain complexity continues to grow you may want to consider moving to an IoC container for managing object life cycles.
I would suggest sticking to MVC as a generic approach to separate your business logic from your view and your controller. This has been well documented and well studied approach, though its the best that we have currently.
Though, it seems like you're trying to use the pattern just for the reason of using the pattern. This is good for learning,but in most application systems I've seen the patterns you have described either don't exist and a simpler approach works or that its a nightmare to maintain.
Please see my previous answer to a question similar like this, that has a video that can help you in your design in the future.
Linky