On Thu, Jun 08, 2017 at 08:46:15AM -0300, Vitor Medina Cruz wrote: > 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.
Well that is the objective of DI to handle the object creation on your behalf. Of course no class is prohibited from creating instances directly, provided it had the necessary dependencies to give to the instance. > Suddenly everything must be created through the DI container, but that is not > true for Service Locator. As I've noted above, DI doesn't restrict you from creating instances. Service Locator gives you a more flexible approach, however it follows that it can be also harder to manage, as the services registered in the locator can (and typically do) change at runtime, which inhibits static reasoning about the dependencies, compared to a pre-fixed configuration. > > 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? In my previous mail I've mentioned Spec doing something of the sorts, but I don't think I've seen it anywhere else. The hand-wiring mostly suffices; sometimes you can see having a method containing the name of the class it will instantiate (and which can be altered in a subclass). My best guess would be that the capabilities of Pharo, such as pluggable closures, and being a live already-running system are more likely to push the programmer towards a different architecture, where incidentally DI's are not such a concern, but I would certainly love to see some deep analysis on this. Peter > > > cheers! > Vitor > > On Wed, Jun 7, 2017 at 9:32 PM, Ben Coman <b...@openinworld.com> wrote: > > > > > > > On Tue, Jun 6, 2017 at 11:48 PM, Attila Magyar <m.magy...@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: > >> > >> http://www.natpryce.com/articles/000783.html > > > > > > 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. > >> > >> > >
