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?

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.

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.