Rozszerzanie klas korowych Opcje

[reptile_rex]

Witam, mam pewien problem z którego rozwiązaniem już trochę się zmagam i nie mogę znaleźć dobrego rozwiązania.

Mianowicie, przykładowo mam strukturę klas korowych:

[PHP] pobierz, plaintext 
Core
   - Messages
      - Messages.php
   - Settings
      - Settings.php
[PHP] pobierz, plaintext 

Jako, że w przyszłości nie chciałbym wymuszać zmiany tych klas, chciałbym zaprojektować mechanizm Override.
Każda z tych klas dziedziczyła by po klasach korowych i mógłbym w ten sposób zmieniać ich metody (przeciążać) bez ingerencji w kod korowy.

[PHP] pobierz, plaintext 
Custom
   - Messages
      - Messages.php
   - Settings
      - Settings.php
[PHP] pobierz, plaintext 

Nie ma problemu z wczytaniem tych klas ponieważ stosuję schemat PSR-0 i mój autoloader sobie z tym poradzi.

Natomiast problem pojawia się w momencie otrzymania obiektu.
Obiekty są u mnie tworzone w sposób normalny czyli przykładowo:

[PHP] pobierz, plaintext 
$object = new \Core\Messages\Messages();
$object2 = new \Core\Settings\Settings();
\Core\Example\ExampleClass::staticMethod();
[PHP] pobierz, plaintext 

W rezultacie - ładowana jest zawsze klasa korowa i zawsze zwracany jest jej obiekt.
Chciałbym doprowadzić do momentu w którym ładowany jest obiekt klasy rozszerzającej (gdy ona istnieje) w innym wypadku ładowanie korowej.

Próbowałem już napisać sobie klasę, która zwraca odpowiedni obiekt, taki prosty Loader, który sprawdza czy klasa posiada swój Override.
Jednak jest to trochę uciążliwe podczas pisania, a w szczególności podczas gdy odwołujemy się do klas abstrakcyjnych i ich metod statycznych,
wtedy przykładowo kod musiałby wyglądać tak:

[PHP] pobierz, plaintext 
// Jezeli klasa normalna - zwracany obiekt
$object = \Service::Core('Klasa\Klasa');
 
// Jezeli klasa abstrakcyjna zwracana jest przestrzen nazw
$namespace = \Service::Core('Abstract\AbstractClass');
$namespace::oneOfStaticMethod();
[PHP] pobierz, plaintext 

Czy macie jakieś inne pomysły na rozwiązanie tego problemu ?

Byłbym wdzięczny za każdą wskazówkę

[Crozin]

Klasy/kod korowy, mechanizm Override - co to za potworki?!

Czy macie jakieś inne pomysły na rozwiązanie tego problemu ?

Problem rozwiązany już wiele, wiele lat temu. Google: Dependency Injection Container - w PHP możesz skorzystać z DIC-a dostępnego w FW Symfony. Jest wystarczająco rozbudowany by nie sprawiać problemów.

[reptile_rex]

Od razu potworki, tak sobie to ponazywałem

Co do DIC to już słyszałem o tym, (Pimple od Symfony).

A wiesz może jak to wygląda po stronie odwołań do klas abstrakcyjnych i ich metod statycznych ?
Bo w przykładach widziałem tylko zastosowanie do obiektów i zastanawiam się czy nie będzie z tym problemów.

[Crozin]

Do klas abstrakcyjnych nie powinieneś się w ogóle odnosić poza ich dziedziczeniem. Z metod/właściwości statycznych również nie powinno się z reguły korzystać. Jeżeli potrzebujesz takową nadpisać na 95% masz błąd w założeniach/projekcie danej klasy.

[reptile_rex]

Z reguły nie korzystam z metod statycznych, ale większość moich klas korowych korzysta ze wzorca Singleton
Więc aby otrzymać ich instancję muszę wykonać statyczne getInstance();

Niektóre klasy korowe mają swoje sterowniki/adaptery, które także są "singletonowe", i aby zwrócić odpowiedni obiekt danego adaptera także muszę wykonać statyczne getInstance();

Ten post edytował reptile_rex 29.12.2012, 13:43:59

[Crozin]

Z reguły nie korzystam z metod statycznych, ale większość moich klas korowych korzysta ze wzorca Singleton

No to już masz pierwszy poważny błąd w projekcie kodu, a co za tym idzie problemy, których przy normalnym projektowaniu nie byłoby.

[reptile_rex]

Sugerujesz, że używanie singletona jest poważnym błędem ?

[phpion]

Chciałbym doprowadzić do momentu w którym ładowany jest obiekt klasy rozszerzającej (gdy ona istnieje) w innym wypadku ładowanie korowej.

Code Igniter oraz Kohana w wersji 2 mają coś takiego. Ściągnij i zobacz jak jest to zrealizowane.

[Crozin]

W niemal wszystkich przypadkach w jakich widzę Singletona jest on użyty niepotrzebnie komplikując jedynie życie. W skrócie: niemal zawsze tak.

[reptile_rex]

Przykładowo mam klasy obsługujące tablice super globalne POST / GET / SESSION etc.
W tym przypadku nie chciałbym pozwolić na tworzenie nowych instancji tych klas poza głównymi.
Więc użycie singletona w tym wypadku wydaje mi się uzasadnione.

@phpion
CodeIgniter jak i zapewne Kohana, która chyba wywodzi się z CodeIgnitera, posiadają własne Loadery o których pisałem w pierwszym poście, dzięki temu mogą zwracać odpowiedni obiekt

Ten post edytował reptile_rex 29.12.2012, 13:57:03

[Crozin]

Przykładowo mam klasy obsługujące tablice super globalne POST / GET / SESSION etc.
W tym przypadku nie chciałbym pozwolić na tworzenie nowych instancji tych klas poza głównymi.
Więc użycie singletona w tym wypadku wydaje mi się uzasadnione.

Idealny przykład obrazujący złe użycie Singletona. Dlaczego niby niemożliwym miałoby być utworzenie dwóch obiektów tego typu? Już pomijam fakt, że przy różnego rodzaju testach będziemy potrzebowali wielu instancji takich obiektów.

@phpion Mechanizm wykorzystywany w Kohanie jest jednym z bardziej porąbanym i niewygodnym jaki w życiu widziałem. Nawet nie sugeruj takich cudów.

[reptile_rex]

Żeby w pełni uzasadnić swoje podejście musiałbym Ci dokładnie opisać założenia i jądro systemu który projektuję, a nie mogę tego zrobić.
Nie mniej jednak zastanowię się jeszcze jakby to wyglądało bez singletona i podejmę decyzję co z tym zrobić dalej.

Dzięki za wszelkie wskazówki