Also realize the Smalltalk image is a container... No need for fancy XML externalization because you can do that with code. I have an app where I wire all kinds of things together in a configuration file which is Smalltalk code and I just compile a method like "wireEverything" that as source has that configuration file. Or just do a Compiler evaluate: aLongConfigurationStringInSmalltalk Any Dictionary can be a "SpringContext" thing. Now decorators with specific features like transaction support etc is not something we have and things like Spring do have. We could take inspiration from Spring Boot. https://projects.spring.io/spring-boot/ Best Regards, Phil On Thu, Jun 8, 2017 at 1:46 PM, Vitor Medina Cruz <vitormcruz@gmail.com> wrote:
Thanks for the links Attila, do you have an alternative one to the http://higherorderlogic.com/2011/07/is-dependency-injection-like-facebook? It seems to be broken.
I also started to also think containers don't worth the effort, but I am still concerned with problems faced with hand wiring everything as Peter clearly exemplified, thanks for the excellent summary and exemplification Peter!
And this is just a basic example. Imagine that the PeopleService also
needs other services for it's use, and those services need more services, and you want to keep everything separated as much as possible... instantiation by hand will simply not cut it
This is exactly my concern! Sure, for small stuff that is not a problem, but what if you have a big app? Now, my experience with containers and Java may be shadowing my vision: people in Java community tend to use anemic model and to create gazzilions layers for even simple stuff, which make the wiring problem even worse. My experiments with a more OO approach and Smalltalk tells me one would need much less need of containers by using proper OO and a less verbose language, but I am not sure.
Keep in mind however that relates primarily to using application
frameworks, where the framework mandates the control, and the framework is the one calling you, and therefore it will also provide you with necessary parts. After all you are not even creating PeopleService class, the framework instantiates it for you and gives it to another services/classes that needed it.
This is true for IoC DI containers, but I don't think it applies for service locator, which, I think, could not be considered a framework approach. Actually, I think being a framework is the big problem of the of the former, since when I start to use an IoC container to create objects I got tied to it in a very basic and pervasive operation of an OO system: object creation. Suddenly everything must be created through the DI container, but that is not true for Service Locator.
However I wouldn't be surprised if the liveness of Smalltalk/Pharo
environment eliminated some of the problems that DI is trying to solve.
That is precisely what I wanted to know. It seems there are no DI counterpart in the Pharo/Smalltalk environment, ok, so what people do to to deal with the above mentioned problem? Hand wiring is suffice? Is there anything in the liveness of Smalltalk/Pharo that eliminates the need for it? People use simple Service Locator, or variations of it?
cheers! Vitor
On Wed, Jun 7, 2017 at 9:32 PM, Ben Coman <btc@openinworld.com> wrote:
On Tue, Jun 6, 2017 at 11:48 PM, Attila Magyar <m.magyar3@gmail.com> wrote:
I don't think using a DI container worth the effort. They add lots of complexities and solve very little. For some reason DI containers became very popular in the Java world, but if you take a look at other programming communities you'll realize that many people are perfectly happy without using these containers. Using DI and using a DI container is orthogonal. As you also said you can just pass dependencies to objects to achieve loose coupling. Yes, you have to do this manually but what's the big deal? We're talking about code with cyclomatic complexity of 1. Calling a constructor is not a problem that need to be solved. Using an external XML configuration to describe object wiring is the worst idea ever.
Here is an article about using plain old object composition to do DI
http://blog.davidpeterson.co.uk/2011/01/object-oriented-example.html
Some more thoughts about the problems associated with DI containers:
I liked this... "the [Dependency Injection] pattern also used to be called "third-party binding" or "third-party connect": some third party is responsible for connecting an object satisfying the service requirements of a component" This makes the subject seem less esoteric. It reminds me of hearing that the first (secret) task when doing a PhD is to invent new terms for common ones, and base your writings on that. Perhaps its the same for consultants and framework developers. ;P Or maybe everything seems esoteric until you have experience with it and I've not done much with Java, certainly not big applications.
Thx Peter for your example and how you prior experience compares to Pharo.
cheers -ben
http://higherorderlogic.com/2011/07/is-dependency-injection- like-facebook
-- View this message in context: http://forum.world.st/Wiring-o bjects-IoC-and-Service-Locator-tp4949280p4949720.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.