Rejestr vs Singleton vs global, co jest lepsze Opcje

[LEW21]

Singleton to takie zmienne superglobalne, utrudniające dodatkowo podmianę pojedynczego komponentu systemu na inny. Jeżeli po prostu użyć zmiennych globalnych (albo nawet rejestru) można przypisać do danej zmiennej/pozycji instancję dowolnej klasy o dowolnej nazwie która ma po prostu określony API współpracujący z danym komponentem. Jeżeli jednak system używa Singletonu to nie jest to możliwe - konieczna jest albo modyfikacja danego komponentu albo utworzenie nowej klasy o nazwie takiej, jakiej rząda ten komponent.

Rejestr działa identycznie jak zmienne globalne, ale jest dużo mniej wygodny w obsłudze i na dodatek jest wolniejszy niż wbudowane w PHP zmienne globalne.

Zmienne globalne też jakimś idealnym rozwiązaniem nie są, ale lepszego po prostu w PHP nie ma. Dlatego właśnie ich używam.

@bim2 @BTW: tak

Ten post edytował LEW21 21.07.2007, 19:23:39

[UDAT]

Najpierw chwila polemiki:
@LEW21

Musiałbym przekazać $filesystem (moja klasa dzięki której zabawa z systemem plików jest obiektowa i banalna (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif) ), $activeUser, $output, $db (to taki przykład, osobiście z tego nie korzystam - trzymam dane w plikach XML) i jeszcze całą masę innych klas, a jak bym się pomylił w kolejności to skutki byłyby opłakane (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

Od czego jest type hinting?

@Cysiaczek

Rejestr ma tą przewagę nad gołymi zmiennymi globalnymi, ze można skutecznie zwiększyć jego funkcjonalność. Można np. składować obiekty jakiegoś konkretnego typu i nie trzeba za każdym razem sprawdzać - poprzez np. instanceof -, czy obiekt jest żadanego typu, czy nie. Tak samo z dodawaniem obiektów do rejestru - metoda dodająca (setter) może automatycznie sprawdzać typ przekazanego obiektu i umieścić w odpowiedniej kolekcji (zyskujemy kategoryzację), albo wręcz go wymusić w swojej definicji i wypluć wyjątek, gdy spróbujemy wprowadzić zły obiekt. Łatwo też sobie wyobrazić, że możemy kontrolować dostęp do obiektów, a nawet możemy filtrować, logować i wykonywac dziesiątki innych operacji, których nie zrobimy w podobnie łatwy i intuicyjny sposób z użyciem globali. Co do API; dlaczego uważasz, że rejestr nie jest przenośny? Ja uważam wręcz odwrotnie - bez rejestru ciężko utrzymac spójność interfejsu - np.

[PHP] pobierz, plaintext 
<?php
$registry->get('userAccountInfo', $user)->getAccountExpireDate(); // przekazujemy nazwę klucza i obiekt klasy User, //który posłuży do naszej identyfikacji
?>
[PHP] pobierz, plaintext 

A skąd pobierzesz instancję rejestru - z innego rejestru? Tworzenie specjalizowanych getterów i setterów spowoduje powstanie God Object(antywzorzec) i nie poprawia architektury aplikacji. Także zrobienie Fabryki rejestrów wydaje się trochę poronione, z których pobierałbyć odpowiedni rejestr.

Czyli coś takiego:

[PHP] pobierz, plaintext 
<?php
RegistryFactory::createRegistry()->getUserAccountInfo();
?>
[PHP] pobierz, plaintext 

Natomiast umożliwienie korzystania z setterów powoduje że mogę np. jakiejś klasie niechcący ustawić inny obiekt, który będzie miał to samo API, ale będzie to inna zupełnie instancja niezwiązana z poprzednią. Pomyśl np. o zmianie obiektu klasy MySQLSession na XMLSession (czy cokolwiek) w trakcie realizacji żądania.

Ja uważam wręcz odwrotnie - bez rejestru ciężko utrzymac spójność interfejsu - np.

[PHP] pobierz, plaintext 
<?php
$registry->get('userAccountInfo', $user)->getAccountExpireDate(); // przekazujemy nazwę klucza i obiekt klasy User, //który posłuży do naszej identyfikacji
?>
[PHP] pobierz, plaintext 

Podejście dobre jedynie do uzyskiwania customizowanych obiektów, jedakże do samego rejestru jako takiego w rozumieniu podanym przez M.Fowlera w PoEAA już nie.



----------------------------------
Teraz moja propozycja:

Czy ten temat nie powinien nazywać się "Sposoby realizacji DI"?
Jeśli nie to nie ma chyba o czym rozmawiać:
global -> zło, Java, C# itd. radzą sobie dobrze bez.
singleton -> brak prawa bytu przy użyciu DI / lub rejestru
rejestr -> użycie jako prymitywny kontener DI (patrz komentarze powyżej) - nie należy mieszać konfigów z DI. Zamiast rejestru można użyć kontenera DI. Statyczne metody nie są rozszerzalne ( przed PHP6 i __callStatic). SingletonRegistry też nie jest rozwiązaniem, lepsza jest statyczna metoda fabryczna, jednak nie jestem zwolennikiem takiego rozwiązania.

W kolejnej odsłonie mojego frameworka chcę użyć normalnego kontenera DI w połączeniu z programowaniem aspektowym i adnotacjami - coś podobnego jak DI w EJB3:

[PHP] pobierz, plaintext 
<?php
class Foo {
/**
   * @Inject(type='Typ podstawowy', name='identyfikator')
   */
   private $injectedProperty;
 
  /**
   * @Inject(type='Typ podstawowy', name='identyfikator')
   */
   private function injectedSetter( $a ) {
 
}
  }
?>
[PHP] pobierz, plaintext 

Podobne podejście (annotacje) wykorzystywane jest, o ile pamiętam w PHP'owym frameworku Stubbles, jednak wymaga specjalnego tworzenia obiektów. Moja implementacja pozwalać będzie na transparentne użycie mechanizmu DI - parz. EJB3 - jednak jest to jeszcze kwestia dopracowania.