> I don't see what is special about this. You can easily arrange instance > creation order with methods on the class-side of your domain classes.
I will not use the term "class", but rather a "service" (service can be just a single class, but that is not always the case). The point of inversion of control is provide the class with what is needed instead of the class creating it on it's own. Sure, you can create class-side helper, however that is very limited, such as the examples/samples as you've demonstrated. To give you an example, imagine that you have a class PeopleService that manages database of people, so it needs a connection to the database. Implemented in a naive way the class would have hard-coded credentials to a MySQL database and it would execute raw SQL queries. This works for a single class, but it creates a mess and mingles concerns; so instead you inverse the control and you provide PeopleService with e.g. a Persistence instance, which is already connected to the database; note however that you cannot just create the Persistence on the class-side, because you wouldn't even know what to instantiate (as you could e.g. use DbPersistence, FilePersistence, ...). 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 So the service locator/DI configuration (whether as annotations or in a XML file) keeps the actual classes separated from concrete instances; the service depends on abstract interfaces, not specific classes; only the conf determines the specific ones, and more often than not there will be several different configurations _at the same time_. To continue with the example you could have one config production using e.g. OraclePersistence, another for development using MySQLPersistance, another for test server using MemoryPersistence, etc. (also with different credentials, and whatnot). 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. Now I don't feel like there are many application frameworks in Pharo, maybe Seaside has something of this sorts? I guess Spec can be a bit framework-y, as the basic spec widgets do not actually know what Morphic counterparts will be created for them, and Spec looks up the actual class in a hard-coded data table (which might as well be a XML file), but that comes closer to ServiceLocator than DI (as Spec widgets should not actually communicate down to morphic). I've used dependency injection for five years at my previous work and frankly I cannot imagine living without it there, but I've never felt the need for it in Pharo. This is probably more related to working in Pharo on completely different things and writing small libraries. However I wouldn't be surprised if the liveness of Smalltalk/Pharo environment eliminated some of the problems that DI is trying to solve. But then again, there are many ways to build systems, and not all need or benefit DI/IoC. Peter > Indeed, the GTTools are set up to work with in-Image sample data. Look at > implementors of #sample and #example. > There was quite some bike-shedding over the naming convention (and I forget > the final result), but hopefully it provide the general idea... > > http://forum.world.st/a-request-to-change-the-meaning-of-lt-example-gt-pragma-td4927360.html > http://forum.world.st/lt-example-gt-lt-examplar-gt-td4911728i20.html > http://forum.world.st/Existing-lt-script-gt-lt-example-gt-pragmas-and-new-GT-needs-td4814903i20.html > > > > > > > I started, however, to question DI as a valid mechanisms because of it's > > complexities and other problems. The article from Fowler provides the > > service locator as an alternative which seems to me much simpler and > > completely fine solution for the problem. > > > > If it seems suitable, then to quote Nike, just do it ;) > > > > > So, to answer you question "Is it any more complicated than that?": In > > the DI approach, yes it can be, but I don't think so in the service locator > > approach. > > > > I am asking here because I wanted to know how people from Smalltalk deal > > with this problem. As it seems there is no standard approach, nor this is > > perceived as a problem... > > > > > DI or Service Locator are both "implementations" of your need. Can we take > step backward to see what is your need? To kick off, I hazard a guess at > some possible needs... > > 1. To switch between configurations to use production data and test data ? > 2. To make this switch during CI testing and production deployment ? > 3. To switch from the command line ? > 4. Want the configuration to editable remotely? e.g. from a text editor? > ? > ... > > > > > You think it is enough to do the wiring by hand? > > > > I'm having trouble understanding this "by hand" concept. > Don't you create the xml configuration file by hand? > You can just as easily > > > > > It is ok to use a service locator approach? Or wouldn't you care about > > that? > > > > If it works, its okay. > > So very generally, I'd avoid starting with any external test data, so as to > not distract myself by that implementation. > I'd copy-paste some test data into the class-side-methods of the domain > classes and hack some instance creation code around them. > Build your first tests around those. Then later, consolidate them via an > InImageTestData object that you'll later replace with ExternalTestData > > > > > > > > > but I'll add, it was so much simpler to understand without all that Java > >> typing boiler plate. > > > > > > Yeah, that's for sure! I am just used to read Java code. > > > > []s, > > Vitor > > > > > > > As an aside, try evaluting "Smalltalk tools inspect" > and debugging "Smalltalk tools browser open" > > cheers -ben
