Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.www.php > #22428 > unrolled thread

Iniezione delle dipendenze vs Service Locator

Back to article view | Back to it.comp.www.php

Contents

  Iniezione delle dipendenze vs Service Locator alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-12-16 12:52 +0100
    Re: Iniezione delle dipendenze vs Service Locator Alessandro Pellizzari <shuriken@amiran.it> - 2018-12-16 17:28 +0000
      Re: Iniezione delle dipendenze vs Service Locator alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-12-17 08:50 +0100
        Re: Iniezione delle dipendenze vs Service Locator Alessandro Pellizzari <shuriken@amiran.it> - 2018-12-17 10:51 +0000
          Re: Iniezione delle dipendenze vs Service Locator alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-12-18 14:36 +0100
            Re: Iniezione delle dipendenze vs Service Locator Alessandro Pellizzari <shuriken@amiran.it> - 2018-12-20 12:42 +0000
              Re: Iniezione delle dipendenze vs Service Locator alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-12-20 14:49 +0100
                Re: Iniezione delle dipendenze vs Service Locator Alessandro Pellizzari <shuriken@amiran.it> - 2018-12-20 17:39 +0000
                  Re: Iniezione delle dipendenze vs Service Locator alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-12-20 19:06 +0100
                    Re: Iniezione delle dipendenze vs Service Locator alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-12-20 19:28 +0100
                    Re: Iniezione delle dipendenze vs Service Locator Alessandro Pellizzari <shuriken@amiran.it> - 2018-12-21 09:42 +0000
                      Re: Iniezione delle dipendenze vs Service Locator alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-12-21 14:47 +0100
                        Re: Iniezione delle dipendenze vs Service Locator fmassei@gmail.com - 2018-12-21 15:45 -0800
                          Re: Iniezione delle dipendenze vs Service Locator alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-12-22 11:55 +0100
                            Re: Iniezione delle dipendenze vs Service Locator Alessandro Pellizzari <shuriken@amiran.it> - 2018-12-22 16:12 +0000
                              Re: Iniezione delle dipendenze vs Service Locator alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-12-22 17:33 +0100
                                Re: Iniezione delle dipendenze vs Service Locator Alessandro Pellizzari <shuriken@amiran.it> - 2018-12-22 16:46 +0000
                                  Re: Iniezione delle dipendenze vs Service Locator alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-12-22 18:37 +0100
                                    Re: Iniezione delle dipendenze vs Service Locator Alessandro Pellizzari <shuriken@amiran.it> - 2018-12-23 15:18 +0000
                                      Re: Iniezione delle dipendenze vs Service Locator alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-12-23 18:43 +0100
                                        Re: Iniezione delle dipendenze vs Service Locator Alessandro Pellizzari <shuriken@amiran.it> - 2018-12-23 17:52 +0000
                                          Re: Iniezione delle dipendenze vs Service Locator alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-12-23 18:58 +0100
                                            Re: Iniezione delle dipendenze vs Service Locator fmassei@gmail.com - 2018-12-24 04:22 -0800
                                              Re: Iniezione delle dipendenze vs Service Locator alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-12-30 14:38 +0100
                          Re: Iniezione delle dipendenze vs Service Locator alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-12-22 13:04 +0100
          Re: Iniezione delle dipendenze vs Service Locator alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-12-20 16:18 +0100
            Re: Iniezione delle dipendenze vs Service Locator Alessandro Pellizzari <shuriken@amiran.it> - 2018-12-20 17:37 +0000
              Re: Iniezione delle dipendenze vs Service Locator alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-12-20 19:21 +0100
                Re: Iniezione delle dipendenze vs Service Locator alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-12-20 20:19 +0100
                  Re: Iniezione delle dipendenze vs Service Locator Alessandro Pellizzari <shuriken@amiran.it> - 2018-12-21 09:45 +0000
    Re: Iniezione delle dipendenze vs Service Locator fmassei@gmail.com - 2018-12-16 18:46 -0800

Page 1 of 2  [1] 2  Next page →

#22428 — Iniezione delle dipendenze vs Service Locator

https://medium.com/@ivorobioff/dependency-injection-vs-service-locator-2bb8484c2e20

cosa ne pensate?

[toc] | [next] | [standalone]

#22429

On 16/12/2018 11:52, alex wrote:

> https://medium.com/@ivorobioff/dependency-injection-vs-service-locator-2bb8484c2e20
> 
> cosa ne pensate?

Dipende quanto controllo vuoi cedere.

Partiamo da una premessa: un SL implementato come nell'esempio è
pessimo, ma è anche vero che la maggior parte degli sviluppatori in
linguaggi dinamici tende a implementarlo così, per poi "vendere" un
framework che lo fa per te.

Il mio punto è che non serve una libreria esterna per implementare un SL:

class ServiceLocator {
  static function getHouse(): House {
    static $house = null;
    if (is_null($house)) {
      $house = new MyHouse();
    }
    return $house;
  }

  static function getWindow(): Window {
    return new Window();
  }
  ...
}

Vantaggi:
1- puoi avere strict typing
2- l'editor sa che oggetto torni e può autocompletarti i metodi
3- l'editor sa se il SL fornisce un service o meno
4- hai un errore (potenzialmente) molto prima da parte del compilatore

Svantaggi:
1- Devi modificare il SL quando aggiungi un servizio

Io non ho dubbi su cosa scegliere. :P

Ora veniamo alla DI. La DI dà allo sviluppatore controllo totale su cosa
passare a un oggetto. Invece di istanziare un oggetto e passargli il SL,
gli passi direttamente le dipendenze. Lo svantaggio è che se istanzi un
oggetto in profondità nel codice devi passare le dipendenze attraverso
tutto l'albero.

Nella mia esperienza conviene sempre tenere la struttura più piatta
possibile, ma siccome non è sempre facile, io preferisco avere un SL che
passo ai livelli più alti, i quali poi usano DI prendendo la roba dal SL
quando istanziano un oggetto.

Esempio insulso. Classico sito web "MV*".

Istanzio i vari repository (interfacce verso DB, servizi esterni,
logger, ecc.) e li infilo nel SL (o li faccio creare dal SL direttamente
passandogli i parametri di connessione, di solito via env vars).

Poi istanzio il router e passo il SL a ogni
Controller/ViewModel/Presenter/quellocheè.

Il controller può chiedere al SL la connessione al DB, il logger, il
mailer e magari il template engine e (se non li usa direttamente) può
istanziare altra roba passandola con DI. Per esempio può create uno
UserRepository passandogli il DB e il logger e prendere i dati, poi
creare un RichMailer passandogli il mailer, il logger e il template
engine, e infine creare un HtmlRenderer passandogli il template engine,
il template in HTML e i dati tornati dallo UserRepository per mostrare
il risultato all'utente.

Insomma: non è che uno esclude l'altro. :)

Bye.

[toc] | [prev] | [next] | [standalone]

#22431

Il 16/12/18 18:28, Alessandro Pellizzari ha scritto:
> On 16/12/2018 11:52, alex wrote:
> 
>> https://medium.com/@ivorobioff/dependency-injection-vs-service-locator-2bb8484c2e20
>>
>> cosa ne pensate?
> 
> Dipende quanto controllo vuoi cedere.
> 
> Partiamo da una premessa: un SL implementato come nell'esempio è
> pessimo,

Perchè?

> Il mio punto è che non serve una libreria esterna per implementare un SL:
> 
> class ServiceLocator {
>    static function getHouse(): House {
>      static $house = null;
>      if (is_null($house)) {
>        $house = new MyHouse();
>      }
>      return $house;
>    }
> 
>    static function getWindow(): Window {
>      return new Window();
>    }
>    ...
> }
> 
> Vantaggi:
> 1- puoi avere strict typing
> 2- l'editor sa che oggetto torni e può autocompletarti i metodi
> 3- l'editor sa se il SL fornisce un service o meno

Cioè?

> Svantaggi:
> 1- Devi modificare il SL quando aggiungi un servizio

Che sarà mai.
Durante la stesura di un progetto modifiche se fanno ovunque :D

> Io non ho dubbi su cosa scegliere. :P
> 
> Ora veniamo alla DI. La DI dà allo sviluppatore controllo totale su cosa
> passare a un oggetto. Invece di istanziare un oggetto e passargli il SL,
> gli passi direttamente le dipendenze. Lo svantaggio è che se istanzi un
> oggetto in profondità nel codice devi passare le dipendenze attraverso
> tutto l'albero.

Anche l`SL è una dipendenza che verrebbe passata allo stesso modo, o 
sbaglio?

> Nella mia esperienza conviene sempre tenere la struttura più piatta
> possibile, ma siccome non è sempre facile, io preferisco avere un SL che
> passo ai livelli più alti, i quali poi usano DI prendendo la roba dal SL
> quando istanziano un oggetto.

Per non violare il principio di DI, gli istanziamenti non andrebbero 
fatti solo in uno dei file principali (index.php, Controller.php, ecc.)?

[toc] | [prev] | [next] | [standalone]

#22432

On 17/12/2018 07:50, alex wrote:

> Il 16/12/18 18:28, Alessandro Pellizzari ha scritto:

>> Partiamo da una premessa: un SL implementato come nell'esempio è
>> pessimo,

> Perchè?

Perché mette in un calderone tutto.

In questo modo non sai che interfaccia implementa il servizio che ti 
viene tornato quando lo richiedi, e soprattutto non sai se c'è un 
servizio con quel nome, costringendoti a verificare ovunque se la 
chiamata a ->get(NomeServizio) ha tornato null, e a gestire l'errore 
ovunque usi il SL.

Se la confronti con il pezzo di codice che ho postato io, è chiaro che 
se un servizio non esiste, non hai il getter per quel servizio, e hai 
errore in compilazione, e se il getter esiste, il getter stesso può 
gestire l'errore in caso il servizio non venga istanziato.

>> Vantaggi:
>> 1- puoi avere strict typing
>> 2- l'editor sa che oggetto torni e può autocompletarti i metodi
>> 3- l'editor sa se il SL fornisce un service o meno
> 
> Cioè?

Vedi sopra: se la classe SL non fornisce il metodo getHouse l'editor può 
dirti che non esiste tramite semplice inspection. Ma l'editor, se chiami 
->get("house") non ha idea se il SL tornerà qualcosa, quindi non ti 
segnala l'errore in caso manchi.

>> Ora veniamo alla DI. La DI dà allo sviluppatore controllo totale su cosa
>> passare a un oggetto. Invece di istanziare un oggetto e passargli il SL,
>> gli passi direttamente le dipendenze. Lo svantaggio è che se istanzi un
>> oggetto in profondità nel codice devi passare le dipendenze attraverso
>> tutto l'albero.
> 
> Anche l`SL è una dipendenza che verrebbe passata allo stesso modo, o 
> sbaglio?

Può esserlo. Io preferisco essere esplicito e passarla con DI, ma 
potrebbe essere un singleton (o un borg, per i pignoli :P) e lo istanzi 
dove ti serve.

> Per non violare il principio di DI, gli istanziamenti non andrebbero 
> fatti solo in uno dei file principali (index.php, Controller.php, ecc.)?

Gli istanziamenti li fai o nel index.php (e poi li infili nel SL) o nel 
SL stesso. In questo modo hai tutto nello stesso posto. Nei controller 
chiedi al SL di darti l'istanza, e lui sa se deve dartene una già fatta 
o deve crearne una al volo.

Questo è uno dei modi. Non è detto che sia il migliore. Spero non sia il 
peggiore, visto che è quello che uso di solito. :D

Bye.

[toc] | [prev] | [next] | [standalone]

#22433

Il 17/12/18 11:51, Alessandro Pellizzari ha scritto:
>> Per non violare il principio di DI, gli istanziamenti non andrebbero 
>> fatti solo in uno dei file principali (index.php, Controller.php, ecc.)?
> 
> Gli istanziamenti li fai o nel index.php (e poi li infili nel SL) o nel 
> SL stesso.

Oppure, per tenere ben organizzato il codice, tramite una factory 
(ServiceLocationFactory)

[toc] | [prev] | [next] | [standalone]

#22442

On 18/12/2018 13:36, alex wrote:

> Oppure, per tenere ben organizzato il codice, tramite una factory 
> (ServiceLocationFactory)

Una Factory dovrebbe servire a creare oggetti che implementano la stessa 
interfaccia.

Quindi una ServiceLocationFactory creerebbe ServiceLocators, non i 
servizi stessi.

Puoi avere diverse factory, una per servizio storato nel SL, ma secondo 
me è un overkill inutile.

Bye.

[toc] | [prev] | [next] | [standalone]

#22443

Il 20/12/18 13:42, Alessandro Pellizzari ha scritto:
> On 18/12/2018 13:36, alex wrote:
> 
>> Oppure, per tenere ben organizzato il codice, tramite una factory 
>> (ServiceLocationFactory)
> 
> Una Factory dovrebbe servire a creare oggetti che implementano la stessa 
> interfaccia.

Ossia?

> Quindi una ServiceLocationFactory creerebbe ServiceLocators, non i 
> servizi stessi.

Addirittura creare più ServiceLocators :-|
Si perderebbe la centralità :D

[toc] | [prev] | [next] | [standalone]

#22446

On 20/12/2018 13:49, alex wrote:

> Il 20/12/18 13:42, Alessandro Pellizzari ha scritto:

>> Una Factory dovrebbe servire a creare oggetti che implementano la 
>> stessa interfaccia.
> 
> Ossia?

function loggerFactory($pippo: int): LoggerInterface {
   switch ($pippo) {
     case 0: return new StubLogger();
     case 1: return new ConsoleLogger();
     case 2: return new SuperLogger();
     default: throw new Exception("Unknown logger");
   }
}

Come vedi, avere un ServiceLocatorFactory non ha senso.

Bye.

[toc] | [prev] | [next] | [standalone]

#22447

Il 20/12/2018 18:39, Alessandro Pellizzari ha scritto:
> On 20/12/2018 13:49, alex wrote:
> 
>> Il 20/12/18 13:42, Alessandro Pellizzari ha scritto:
> 
>>> Una Factory dovrebbe servire a creare oggetti che implementano la 
>>> stessa interfaccia.
>>
>> Ossia?
> 
> function loggerFactory($pippo: int): LoggerInterface {
>    switch ($pippo) {
>      case 0: return new StubLogger();
>      case 1: return new ConsoleLogger();
>      case 2: return new SuperLogger();
>      default: throw new Exception("Unknown logger");
>    }
> }
> 
> Come vedi, avere un ServiceLocatorFactory non ha senso.
> 
> Bye.

E questa cosa cos'è?
Poi i logger, gli gnomi, i folletti?

Senti, per come la intendo io, guarda qua

class ServiceLocatorFactory {
  function crate(): ServiceLocator {
     $a = ...;
     $b = ...;
     $c = ...;
     return new ServiceLocator($a,$b,$c);
   }
  }
}

[toc] | [prev] | [next] | [standalone]

#22449

Il 20/12/2018 19:06, alex ha scritto:
> 
> class ServiceLocatorFactory {
>   function crate(): ServiceLocator {
>      $a = ...;
>      $b = ...;
>      $c = ...;
>      return new ServiceLocator($a,$b,$c);
>    }
>   }
> }

Altro esempio

class ServiceLocatorFactory {
  function crate(): ServiceLocator {
     $x = new ServiceLocator();

     $x->setServiceA(new A);
     $x->setServiceB(new B);
     $x->setServiceC(new C);

     return $x;
   }
  }
}

[toc] | [prev] | [next] | [standalone]

#22453

On 20/12/2018 18:06, alex wrote:

> Senti, per come la intendo io, guarda qua
> 
> class ServiceLocatorFactory {
>   function crate(): ServiceLocator {
>      $a = ...;
>      $b = ...;
>      $c = ...;
>      return new ServiceLocator($a,$b,$c);
>    }
>   }
> }

Questa non e` una Factory. Al massimo e` un Builder, ma nemmeno quello.

Una Factory (fabbrica, in italiano) produce piu` di un oggetto.

Se devi costruirne solo uno, tanto vale farlo nel costruttore del
ServiceLocator (o nell'istanziatore, se e` un singleton).

Bye.

[toc] | [prev] | [next] | [standalone]

#22456

Il 21/12/18 10:42, Alessandro Pellizzari ha scritto:
> Questa non e` una Factory. Al massimo e` un Builder, ma nemmeno quello.

Differenza tra factory e builder?

[toc] | [prev] | [next] | [standalone]

#22458

On Friday, December 21, 2018 at 8:47:45 AM UTC-5, alex wrote:
> Il 21/12/18 10:42, Alessandro Pellizzari ha scritto:
> > Questa non e` una Factory. Al massimo e` un Builder, ma nemmeno quello.
> 
> Differenza tra factory e builder?
>

Un factory costruisce un oggetto al volo e lo ritorna, solitamente è giusto
un wrapper per un costruttore.
Un builder restituisce un oggetto non costruibile in un singolo step, e.g.
quando solo il costruttore non da un oggetto utilizzabile.

Risposta a parte, non capisco perché parti per la tangente quando qualcuno
ti cerca di spiegare in dettaglio qualcosa che chiedi. Per questo thread,
ad esempio, questa era l'ultima domanda che sarebbe venuta in mente a
qualsiasi altra persona. Così, anche se magari non è vero, sembra che
scrivi per scrivere, e non leggi con attenzione chi s'impegna regalandoti
il suo tempo. M2C.


Ciao!

[toc] | [prev] | [next] | [standalone]

#22460

Il 22/12/18 00:45, fmassei@gmail.com ha scritto:
> Un factory costruisce un oggetto al volo e lo ritorna, solitamente è giusto
> un wrapper per un costruttore.

O restituisce una specifica versione di un oggetto che però implementa 
sempre la stessa interfaccia (come ha illustrato Alessandro)?

> Un builder restituisce un oggetto non costruibile in un singolo step, e.g.
> quando solo il costruttore non da un oggetto utilizzabile.

Ad esempio?

[toc] | [prev] | [next] | [standalone]

#22462

On 22/12/2018 10:55, alex wrote:

> Il 22/12/18 00:45, fmassei@gmail.com ha scritto:
>> Un factory costruisce un oggetto al volo e lo ritorna, solitamente è giusto
>> un wrapper per un costruttore.
> 
> O restituisce una specifica versione di un oggetto che però implementa 
> sempre la stessa interfaccia (come ha illustrato Alessandro)?

Per definizione, un oggetto implementa sempre la stessa interfaccia. Non
esistono "versioni di un oggetto".

Una factory restituisce oggetti di classi diverse, che implementano la
stessa interfaccia.

Se una factory torna sempre lo stesso oggetto della stessa classe, che
implementa la stessa interfaccia, puoi eliminare la factory e
l'interfaccia, che non servono a niente, e ti rimane solo la classe col
suo costruttore.

>> Un builder restituisce un oggetto non costruibile in un singolo step, e.g.
>> quando solo il costruttore non da un oggetto utilizzabile.
> 
> Ad esempio?

Ad esempio

$controller = ControllerBuilder::create()
  ->withRequest($req)
  ->withOutput(new HtmlRenderer())
  ->withDb($contentDb)
  ->build();

Il controller non può funzionare senza una Request, senza una
connessione al DB e senza sapere dove mandare l'output.

Se, per qualsiasi motivo, non hai tutte le informazioni disponibili
quando lo crei, puoi creare un builder e passarlo alle varie fasi della
pipeline, che aggiungono i pezzi che mancano, e alla fine chiami
`build()` che costruisce il Controller vero e proprio, da usare nel Router.

Se chiami `build` senza aver settato tutte le parti richieste, torna un
errore e non ti restituisce il controller. Se non chiami `build` alla
fine, hai un ControllerBuilder e non un Controller, quindi non hai
l'interfaccia adatta al Router.

È praticamente Dependency Injection fatta a passi successivi, invece che
passare tutto nel costruttore dell'oggetto.

Sono tecniche che si usano spesso in linguaggi strictly typed, e in PHP
perdono un po' di senso, ma sono comunque utili per catturare errori in
certe circostanze.

Bye.

[toc] | [prev] | [next] | [standalone]

#22463

Il 22/12/2018 17:12, Alessandro Pellizzari ha scritto:
> Se chiami `build` senza aver settato tutte le parti richieste, torna un
> errore e non ti restituisce il controller

Quindi naturalmente all'interno di build() bisogna prima di tutto 
verificare che tutto sia stato settato a dovere?

[toc] | [prev] | [next] | [standalone]

#22464

On 22/12/2018 16:33, alex wrote:

> Il 22/12/2018 17:12, Alessandro Pellizzari ha scritto:
>> Se chiami `build` senza aver settato tutte le parti richieste, torna un
>> errore e non ti restituisce il controller
> 
> Quindi naturalmente all'interno di build() bisogna prima di tutto 
> verificare che tutto sia stato settato a dovere?

Normalmente la `build()` chiama semplicemente il costruttore
dell'oggetto che sta generando, passandogli tutte le dipendenze.

A quel punto è il costruttore stesso che deve verificare che le
dipendenze siano valide (tramite strict-typing e `if !is_null(...)`, se
serve).

In questo modo hai i controlli in un posto solo (il costruttore
dell'oggetto finito) e non importa come lo crei, avrai comunque gli errori.

I Builder solitamente sono abbastanza "stupidi" come classi.

Bye.

[toc] | [prev] | [next] | [standalone]

#22465

Il 22/12/2018 17:46, Alessandro Pellizzari ha scritto:
> Normalmente la `build()` chiama semplicemente il costruttore
> dell'oggetto che sta generando, passandogli tutte le dipendenze.

Appunto, quindi il metodo create() cosa fa?

[toc] | [prev] | [next] | [standalone]

#22466

On 22/12/2018 17:37, alex wrote:

> Il 22/12/2018 17:46, Alessandro Pellizzari ha scritto:

>> Normalmente la `build()` chiama semplicemente il costruttore
>> dell'oggetto che sta generando, passandogli tutte le dipendenze.
> 
> Appunto, quindi il metodo create() cosa fa?

Te lo spiego con un esempio:

class Controller {
  private $request;
  private $output;
  private $logger;

  public function __construct($req, $out, $logger) {
    if (is_null($req) || is_null($out) || is_null($logger)) {
      throw new Exception('Missing dependencies');
    }
    $this->request = $req;
    $this->output = $out;
    $this->logger = $logger;
  }
}

class ControllerBuilder {
  private $request;
  private $output;
  private $logger;

  public static function create() {
    $builder = new ControllerBuilder();
    $builder->logger = new ConsoleLogger();
  }

  public function withRequest($req) {
    $this->request = $req;
    return $this;
  }

  public function withoutput($out) {
    $this->output = $out;
    return $this;
  }

  public function withLogger($logger) {
    $this->logger = $logger;
    return $this;
  }

  public function build() {
    return new Controller($this->request, $this->output, $this->logger);
  }
}

Come dicevo: assolutamente stupido. Il suo unico scopo è di permetterti
di costruire un oggetto a step, ed eventualmente di definire dei valori
di default.

Bye.

[toc] | [prev] | [next] | [standalone]

#22467

Il 23/12/2018 16:18, Alessandro Pellizzari ha scritto:
>    public static function create() {
>      $builder = new ControllerBuilder();
>      $builder->logger = new ConsoleLogger();
>    }

??????????????????????????????????????????
bohhhhhhhhhh :D

$builder a chi ed a che serve????

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | it.comp.www.php

csiph-web