Forum PHP.pl

Czy jest mi ktoś w stanie powiedzieć, czy dobrze rozumiem?
Service Locator w moim rozumieniu działa jako "baza" obiektów wytworzonych dla działania konkretnych części aplikacji. Z tego, co widziałem w przykładach, jest to implementowane w stylu:

[PHP] pobierz, plaintext 
class sl
{
    public function getDB()
    {
        return new DB();
    }
 
    public function getCostam()
    {
        return new Costam();
    }
}
[PHP] pobierz, plaintext 

ale w tym przykładzie zwracane są nowe instancje.
Czy wzorzec ten opiera się też o zwracanie obiektów podobnie do działania Singletonu? A może to już inny wzorzec?
Powiedzmy, że do powyższej klasy dodalibyśmy właściwość

[PHP] pobierz, plaintext 
protected $instances = [];
[PHP] pobierz, plaintext 

a na przykład w getDB() sprawdzalibyśmy, czy $instances posiada już instancję konkretnego obiektu, i jeśli tak, to zwraca właśnie ją, a w przeciwnym wypadku tworzy nową i dopisuje ją do indexu.
Powyższy przykład to TYLKO PRZYKŁAD - więc uwagi typu "użyłbym innej metody faktoryzującej" raczej nic nie wniosą - chcę się dowiedzieć tylko, czy dobrze pojmuję temat.

//edit: jeśli przechowywałby instancje, to chyba byłoby w konflikcie z wzorcem Registry - ale czy oba na raz można użyć dla jednego celu?

Ten post edytował czychacz 14.03.2015, 17:36:07

Hej,

Wg mojego rozumienia to co napisałeś, to prosty DI container. Do wzorca service locator dojdziesz, umożliwiając użycie tego containera obiektom, które nie powinny o nim wiedzieć, np. wstrzykując go jako zależność lub pakując w singleton.

To czy metoda getServiceAbc() zwróci każdorazowo nowy obiekt czy wykorzysta już istniejący nie ma znaczenia z punktu widzenia tego (anty)wzorca. Część może działać tak, część inaczej. Generalnie Twój przykład jest poprawny.

SL nie stoi w sprzeczności z rejestrem, przy czym może go wykorzystywać własnie na przykład w celu zwracania tych samych obiektów usług.

Ten post edytował Crozin 20.03.2015, 10:58:48

ServiceLocator jest to wzorzec, którego zadaniem jest przejęcie kontroli nad tworzeniem obiektów (serwisów), o które go poprosisz, wraz ze wszystkimi dependency które te obiekty potrzebują. To czy za każdym razem zwróci nowy obiekt, czy będzie je pobierał z jakiejś puli obiektów, czy może będzie to multiton, singleton czy customowa fabryka obiektów to już szczegóły implementacyjne. Większość szanowanych się ServiceLocatorów pozwala zdefiniować w bootstrapie config, w którym możesz określić które obiekty jak mają być tworzone, np.

"jeżeli programista poprosi o obiekt A, stwórz nowy A, za kazdym razem
jeżeli programista poprosi o obiekt B, stwórz B jeśli nie istnieje i go zapamiętaj, jeśli istnieje zwróć ten zapamiętany"
itd.

Różni się od Dependency Injection kierunkiem przepływu informacji. W przypadku ServiceLocatora, to dana klasa go odpytuje o obiekty. W przypadku DependencyInjection, wszystkie potrzebne obiekty są injectowane do wewnątrz tworzonej klasy.

ServiceLocator z punktu implementacyjnego może przypominać albo być wręcz identyczny z rejestrem, ale cel działania jest inny.
1. ServiceLocator definiuje metody tworzenia obiektów (posiadających logikę), gdy rejestr definiuje dostęp do statycznych wartości i modeli (nie posiadajacych logiki).
2. ServiceLocator ma na starcie aplikacji zdefiniowany config, który nie zmienia się w trakcie działania aplikacji i po fazie bootstrapu jest w pełni funkcjonalny, rejestr z kolei może zmieniać swój stan (zapamiętane wartości) cały czas w trakcie działania aplikacji.