On Tue, Jun 6, 2017 at 5:11 AM, Stephane Ducasse <[hidden email]> wrote:

Tx ben.

When I see all this complexity for something that looks not that complex: I prefer to pass the class and get done. 

May be I missed something obvious... but when I see something too complex I start to get worried. 

I think that thinking about the contract between classes at runtime is important and to me a MovieLister should be using at runtime and instance of the *Finder* 

Now needing an extra class just to set this should really be evaluated with the tradeoff: "flexibility win" (our simple solution is still really flexible - I decide when I want to pass the correct finder) vs. the code and conceptual bloat. 

I'm happy not to face the hyper super over engineering of Java "solutions".

I like the "Of course this just shifts the burden a tad, we still have to get the locator into the lister"

but the solution is super simple let us use another "Singleton and a Factory...." :)

Stef

On Mon, Jun 5, 2017 at 8:43 PM, Ben Coman <[hidden email]> wrote:

On Tue, Jun 6, 2017 at 1:26 AM, Vitor Medina Cruz <[hidden email]> wrote:

Thanks for the answer Ben and Stephane. 

I already read A Mentoring Course on Smalltalk, Valloud, there is nothing there I could use in this case :( . I will look after for The Design Patterns Smalltalk Companion. Most of the sources provided I already know of or went in the same lines lines of what I have already found. 

About TDD, I am experienced with the discipline and have tested it on Pharo living system already, but I could not understand how this is related with object wiring, DI and service locator.

I guess I don't properly understand your need and those topics.  That was my quick pass.  Now if I take the time to actually read Fowler's long article

"the inversion is about how they lookup a plugin implementation ... to ensure that any user of a plugin follows some convention that allows a separate assembler module to inject the implementation into the lister."

"The basic idea of the Dependency Injection is to have a separate object, an assembler, that populates a field in the lister class with an appropriate implementation for the finder interface. There are three main styles of dependency injection. The names I'm using for them are Constructor Injection, Setter Injection, and Interface Injection."

Now there was too much syntactical noise in those Java examples for me to think clearly, so I converted them all to Smalltalk.

##CONSTRUCTOR INJECTION

Object subclass: MovieLister

    instanceVariables: 'finder'

MovieLister class >> newWith: aFinder

    ^ self basicNew initializeWith: aFinder

MovieLister >> initializeWith: aFinder

    finder := aFinder

ColonMovieFinder class >> newWith: aFilename

    ^ self basicNew initializeWith: aFilename

ColonMovieFinder >> initializeWith: aFilename

    filename := aFilename.

ConstructorInjectionContainer >> new

    container := DefaultContainer new.  "the article doesn't specify where this comes from"

    finderParams := ConstantParameter newWith: 'movies1.txt'.

    container registerComponentInterface: MovieFinderInterface 

                          implementation: ColonMovieFinder 

                          params: finderParams.

    container registerComponentImplementation: MovieLister

    ^container

to be used like this...

ConstructorInjectionTest >> testWithContainer

    container := ConstructorInjectionContainer new.

    lister := container getComponentInstance( MovieLister ).

    movies = lister moviesDirectedBy: 'Sergio Leone'.

    self assert: (movies includes: 'Once Upon a Time in the West')

The article poorly defines registerComponentXXX: or getComponentInstance:

methods, so I don't dwell on them.  I presume its little relevant to the main theme.

##SETTER INJECTION

MovieLister >> setFinder: aFinder

    finder := aFinder.

ColonMovieFinder >> setFilename: aFilename

    filename := aFilename.

SetterInjectionTest >> testWithConfigurationFile

    ctx := SomeXmlApplicationConfiguration on: 'config.xml'.

    lister := ctx getConfigOf: 'MovieLister'.

    movies = lister moviesDirectedBy: 'Sergio Leone'.

    self assert: (movies includes: 'Once Upon a Time in the West')

##INTERFACE INJECTION

MovieLister >> injectFinder: aFinder

    finder := aFinder

ColonMovieFinder >> injectFilename: aFilename

    filename := aFilename

InterfaceInjectionTest >> configureContainer

    container := InterfaceInjectionContainer new.

    self registerComponents.

    self registerInjectors.

    container start.

InterfaceInjectionTest >> registerComponents

    container registerComponent: 'MovieLister' with: MovieLister.

    container registerComponent: 'MovieFinder' with: ColonMovieFinder.

InterfaceInjectionTest >> registerInjectors

    container registerInjector: Injector  with: (container lookup: 'MovieFinder').

    container registerInjector: InjectorFinderFilename  with: FinderFilenameInjector new.

ColonMovieFinder >> inject: anObject

    anObject injectFinder: self.

FinderFilenameInjector >> inject: anObject

    anObject injectFilename: 'movies1.txt'.

InterfaceInjectionTester >> testInterface

    self configureContainer.

    lister := container lookup: 'MovieLister'.

    movies = lister moviesDirectedBy: 'Sergio Leone'.

    self assert: (movies includes: 'Once Upon a Time in the West')

The article doesn't define InterfaceInjectionContainer, but I guess it could look like this...

InterfaceInjectionContainer >> registerComponent: componentName with: aComponent

    container ifNil: [ container := Dictionary new].

    container at: componentName put: aComponent

InterfaceInjectionContainer >> lookup: componentName

    ^ container at: componentName

    

##SERVICE LOCATOR

"The basic idea behind a service locator is to have an object that knows how to get hold of all of the services that an application might need. So a service locator for this application would have a method that returns a movie finder when one is needed. Of course this just shifts the burden a tad, we still have to get the locator into the lister"

MovieLister >> initialize

    finder := ServiceLocator movieFinder.

Object subclass: ServiceLocator

    instanceVariable: 'movieFinder'

    classVariable: 'SoleInstance'

ServiceLocator class >> load: aServiceLocator

    SoleInstance := aServiceLocator

ServiceLocator class >> soleInstance  

    ^ SoleInstance

ServiceLocator class >> movieFinder

    ^ self soleInstance movieFinder

ServiceLocator >> movieFinder

    ^movieFinder

ServiceLocatorTest >> configure

    ServiceLocator load: (ServiceLocator newWith: (ColonMovieFinder newWith: 'movies1.txt')) 

ServiceLocator class >> newWith: aMovieFinder

    ^ self basicNew initializeWithFinder: aMovieFinder

ServiceLocator >> initializeWithFinder: aMovieFinder

    movieFinder := aMovieFinder

ServiceLocatorTest >> testSimple

    self configure.

    lister := MovieLister new.

    movies = lister moviesDirectedBy: 'Sergio Leone'.

    self assert: (movies includes: 'Once Upon a Time in the West')

   

So it seems that a service locator is just a Singleton pattern having a class variable for each service of interest ??

It was late and I mispoke here, of course this should have said... 

* a Singleton pattern having an instance variable for each service of interest

* a Singleton pattern having a getter method (with hidden implementation) for each service of interest

 

So in good faith** I ask... "Is it any more complicated than that?" 

**Since its taken me a couple of hours to convert the Java to this point so I stopped reading to seek your feedback. 

but I'll add, it was so much simpler to understand without all that Java typing boiler plate.

cheers -ben

 

Is that enough insight to adapt to your needs, or is there something else further down the article that invalidates my analysis?

From ben:

"I'm not really familiar with IoC or DI patterns, so just taking your example at face value, in Pharo I'd do...

MovieLister>>moviesDirectedBy: director
    allMovies := finder allMovies.
    ^ allMovies select: [ :movie | movie getDirector = director ].
    "although typically #getDirector would be renamed #director"

MovieLister>>finder: movieFinder
    finder := movieFinder.

to be used like this...
    lister := MovieLister new finder: (ColonDelimitedMovieFinder on: 'movies1.txt').
    movies := lister moviesDirectedBy: 'Tarantino'."

So per Fowler, the above is equivalent to "Setter Injection with Spring"

 

and Stephane:

Why don't you simply pass the class and use that class in your MovieLister?

MovieLister new
     finderClass: MySuperCoolFinderClass

...
MovieLister finder
      finderClass new .....

What is wrong with that.

That was what I meant when I said: "I know that in Smalltalk I can make MovieLister to receive, upon construction, a class representing MovieFinder and call it construction message.". The code I had in mind is a bit of mix from the one provided by you both:

MovieLister>>moviesDirectedBy: director
    allMovies := finder allMovies.
    ^ allMovies select: [ :movie | movie getDirector = director ].
    "although typically #getDirector would be renamed #director"

MovieLister>>finder: aMovieFinderBuilder
    finder := aMovieFinderClass new.

to be used like this...
    lister := MovieLister new finder: (ColonDelimitedMovieFinder builderOn: 'movies1.txt').
    movies := lister moviesDirectedBy: 'Tarantino'."

But that means I will have to wire dependencies by hand whenever I create a MovieLister and seek through code when and if those dependencies change. When there are lot's of dependencies it's is a considerable and tedious work. Let's see an image from Fowlers article:

In this case, the service locator provides me with an instance and I configure the instance in the assembler, the scheme is alike for an IoC, and that would mean my implementation could be like this:

MovieLister>>moviesDirectedBy: director
    allMovies := finder allMovies.
    ^ allMovies select: [ :movie | movie getDirector = director ].
    "although typically #getDirector would be renamed #director"

MovieLister>>initialize
    finder := ServiceLocator locate: FinderClass   <--- This would bring the instance of finder class configured by the assembler

No, like this... 

    finder := ServiceLocation movieFinder.

Now if you want to store a class rather than an instance as I did higher up, you just do this...

Object subclass: ServiceLocator

    instanceVariable: 'movieFinderClass'

    classVariable: 'SoleInstance'

ServiceLocator class >> movieFinder

    ^ self soleInstance movieFinderClass new

 

to be used like this...
    lister := MovieLister new.
    movies := lister moviesDirectedBy: 'Tarantino'."

and the assembler:

Assember class>>configure:

aMap put: (ColonDelimitedMovieFinder builderOn: 'movies1.txt') at: FinderClass 

Assembler class>>configure

    ServiceLocator load: 
          (ServiceLocator new
               movieFinder: (ColonMovieFinder newWith: 'movies1.txt')

               otherService: MyCustomService new) 

 

My assembler and service locator could be even more elaborated, and provide a different MovieFinder in test scope, for different classes or wharever. 

Really, the test should not be updating the class variable global like this...

ServiceLocatorTest >> configure

    ServiceLocator load: (ServiceLocator newWith: (ColonMovieFinder newWith: 'movies1.txt')) 

you probably want something like (its rough but shows the point...)

Object subclass: #MovieLister

    instanceVariables: 'serviceLocator'

MovieLister >> initialize

    serviceLocator ifNil: [ serviceLocator := ServiceLocator soleInstance ].

    finder := serviceLocator movieFinder.

 

MovieLister class >> newWithServiceLocator: aServiceLocator

    ^ (self basicNew initializeWithServiceLocator: aServiceLocator) initialize.

MovieLister >> initializeWithServiceLocator: aServiceLocator

    serviceLocator := aServiceLocator

ServiceLocatorTest >> testSimple2

    lister := MovieLister newWithServiceLocator: (ServiceLocator newWith: (ColonMovieFinder newWith: 'movies1.txt')).

    movies = lister moviesDirectedBy: 'Sergio Leone'.

    self assert: (movies includes: 'Once Upon a Time in the West')

cheers -ben

 

It is a little convenience for Smalltalk, I will give that, but I was wandering if there was something alike in Pharo, by your answers I assuming there is nothing like that.

On Mon, Jun 5, 2017 at 6:41 AM, Stephane Ducasse <[hidden email]> wrote:

Why don't you simply pass the class and use that class in your MovieLister?

MovieLister new
     finderClass: MySuperCoolFinderClass

...
MovieLister finder
      finderClass new .....

What is wrong with that.

If you do not want to have a reference at runtime to a Finder then you
need to use announcement and registration.

Stef

On Sun, Jun 4, 2017 at 11:17 PM, Vitor Medina Cruz <[hidden email]> wrote:
> Hello,
>
> I would like to know how people in Pharo ecosystem do to deal with object
> wiring, as described by Marting Fowler in
> https://martinfowler.com/articles/injection.html#FormsOfDependencyInjection:
>
> "A common issue to deal with is how to wire together different elements: how
> do you fit together this web controller architecture with that database
> interface backing when they were built by different teams with little
> knowledge of each other."
>
> He gives an example, I will leave it in java as it is simple enough to
> understand:
>
> "class MovieLister...
>
>   public Movie[] moviesDirectedBy(String arg) {
>       List allMovies = finder.findAll();
>       for (Iterator it = allMovies.iterator(); it.hasNext();) {
>           Movie movie = (Movie) it.next();
>           if (!movie.getDirector().equals(arg)) it.remove();
>       }
>       return (Movie[]) allMovies.toArray(new Movie[allMovies.size()]);
>
>   }"
>
> The question is how to provide the finder object in a decoupled matter, a
> naive approach would be:
>
> " private MovieFinder finder;
>
>   public MovieLister() {
>     finder = new ColonDelimitedMovieFinder("movies1.txt");
>
>   }"
>
> Which couples the MovieLister to the specific ColonDelimitedMovieFinder
> class.
>
> Fowler explains how to decouple using an IoC framework or a Service Locator.
> In Java and .Net IoC is used most of the time. I Googled how this problem is
> approached in Smalltalk/Pharo, and I generally I found answers "that is easy
> to do in Smalltalk, so there is no need of a framework", what I miss is a
> description on *how* to do that:
>
> https://stackoverflow.com/questions/243905/smalltalk-and-ioc
> https://stackoverflow.com/questions/2684326/is-there-a-dependency-injection-framework-for-smalltalk
> https://stackoverflow.com/questions/243905/smalltalk-and-ioc/347477#347477
>
> I know that in Smalltalk I can make MovieLister to receive, upon
> construction, a class representing MovieFinder and call it construction
> message. As long an object that responds to this message is provided, I can
> create as many derivations I want and the MovieLister will be decoupled from
> the MovieFinder. That way, however, I still have to wire things by hand, and
> I am not sure if this is what I am supposed to do in order to solve the
> decouple problem.
>
> Can you explain me how this is done in Pharo? It's is usually wiring by
> hand? Is there a simple construction that deals with the wiring problem that
> I cannot foresee?
>
> Thanks in advance,
> Vitor
>
>
>