Hejka.

Ostatnio po przeczytaniu paru tekstów o wzorcach zacząłem się zastanawiać nad tworzeniem instancji obiektów w systemie (lepiej późno niż w cale ). Czy nie zacząć stosować swojego rodzaju „fabryki” tak, aby mieć większą kontrolę nad tym, co się dzieje w systemie jeśli idzie o obiekty. Zaciekawił mnie ten „problem”, a jako, że nie znalazłem podobnych wątków postanowiłem napisać o tym i zapytać się, co o tym sądzicie.

Generalnie od jakiegoś czasu w swoim systemiku korzystam z funkcji __autoload() przy ładowaniu plików z klasami. I samo w sobie jest to IMHO ok, tyle, że od pewnego momentu zaczęło mnie drażnić przekazywanie obiektów w parametrach nowo tworzonych obiektów. Fajnie by było, żeby sam skrypt dbał o to jaki plik załadować, jeżeli dany obiekt potrzebuje instancji innych klas do działania to niech je sobie sam stworzy, jeśli rozszerza jakaś klasę to niech zanim stworzy tą właściwą zapewni dostęp do wszystkich klas nadrzędnych po których ona dziedziczy, podobnie z interfejsami… My tylko chcemy stworzyć np.: obiekt klasy Session, a to że on wymaga PDO (w konstruktorze wymaga przekazania obiektu typu PDO) to nie nasz problem.
Skąd by było wiadomo, co i jak? Z pliku xml, tablicy... w której to była by definicja wszystkich klas systemu, z których korzysta. Te dane z pliku, czy innego źródła były by ładowane przez jakaś klase typu ClassConfigurationLoader, która tworzyła by tablice, a w niej pod kluczem w postaci "nazwa klasy" wsadzał by wartość w postaci stworzonego obiektu zapewniającego dostęp do wszystkich danych z konfiguracji.
Za tworzenie obiektów dostępnych klas odpowiadala by klasa np: ObjectGenerator. W jednej z metod podawali bysmy tylko nazwe interesujacej nas klasy, a skrypt, wg. konfiguracji, sprawdzal by czy ta klasa korzysta z innych klas, czy po jakis dziedziczy itd.
Dodatkowo ObjectGenerator moglby byc wywolywan z poziomu klasy ObjectManager, ktory to moglby zliczac wywolywania, czas generowania, cacheowac (singleton) itd.
Co sądzicie o takim podejściu? Napewno, nie jest to nic nowatorskiego, ale ciekawy jestem waszych opinii, wad, zalet, ktorych moze ja nie dostrzegam. Poza tym ciekawy jestem tez waszego sposobu tworzenia obiektow i ich przekazywania w parametrach. Czy raczej uzywacie jednego modulu do powolywania obiektow, czy wszedzie new?

jeszcze przyklad jak mogla by wygladac taka konfiguracja klas (na przykladzie tablicy, ale nie ma problemu by bylo to xml, czy inne zrodlo):

[PHP] pobierz, plaintext 
<?php
array(
'Pdo' => array(
'name'=>'Pdo',
'file' => false,
'singleton' => true,
'extensions' => array(),
'interfaces' => array(),
'params' => array('mysql:ble ble','login','pass')),
 
'Session' => array(
'name'=>'HttpSession',
'file' => 'session.php',
'singleton' => true,
'extensions' => array('oPdo'),
'interfaces' => array('ISession'),
'params' => array())
);
?>
[PHP] pobierz, plaintext 

Nie najgorzej. Nie rozumiem po co Ci interfejsy i rozszerzenia.
IMHO, w bardziej rozbudowanych systemach nie przekazywać obiektów jako parametry, tylko dziedziczyć je.
W sumie to tyle wielkim skrótem

pozdrawiam

Zanim spróbujesz utworzyć obiekt klasy x, musisz sprawdzić czy czasem nie dziedziczy on po innej klasie, która nie została dotychczas załadowana lub interfejsie. Jeżeli tak to najpierw musisz załadować odpowiednie pliki klas i interfejsów. Dlatego te informacje są dosyć potrzebne w konfiguracji. Można się co najwyżej przyczepić, czy klasy maja być zapisane w tablicy, bo w php jest możliwość dziedziczenia tylko po 1 klasie na danym poziomie.

Btw. troszkę źle napisałem przykład. Obiekt Pdo powinien być przekazany jako parametr, a nie jako rodzic (Session extends Pdo):

[PHP] pobierz, plaintext 
<?php
array(
'Pdo' => array(
'name'=>'Pdo',
'file' => false,
'singleton' => true,
'extensions' => array(),
'interfaces' => array(),
'params' => array('mysql:ble ble','login','pass')),
 
'HttpSession' => array(
'name'=>'HttpSession',
'file' => 'session.php',
'singleton' => true,
'extensions' => array(),
'interfaces' => array('ISession'),
'params' => array('Pdo'))
);
?>
[PHP] pobierz, plaintext 

Zatem obiekt Pdo jest przekazywany w parametrze (automatycznie tworzony przy instancji Session), implementuje też interfejs ISession, więc zanim utworzy obiekt Session, musi zapewnić plik z tym interfejsem. Więc dopisujemy:

[PHP] pobierz, plaintext 
<?php
'ISession' => array(
'name' => 'ISession',
'file' => 'session.interface.php'
)
?>
[PHP] pobierz, plaintext 

Dodatkowo klasa HttpSession może rozszerzać klasę Session i wtedy dodajemy definicje Session, a do parametru extensions w definicji HttpSession dodajemy 'Session' i wtedy na podobnej zasadzie skrypt zanim utworzy obiekt HttpSession zapewni także dostęp do pliku z klasa Session (require_once).

Pytanie tylko, czy definicje interfejsów powinny być w tym samym pliku/tablicy, co definicje klas?
Pozostaje tez problem static Bo narazie wszystko działa na zasadzie operatora new. Wprawdzie sprawa singletona jest przerzucona na barki klasy ObjectManager, która to w momencie 'simgleton'=>true zapisuje obiekt w cache`u, ale co w przypadku klas, na które składają się tylko metody statyczne?
Tego jeszcze nie wiem, jakieś pomysły?

Pozdrawiam i dzięki za opinie Ociu.

Dalej uważam, ze definicje iterfejsów i rozszerzeń nie są konieczne. Nie piszesz kodu, który Ci nie będzie potrzebny. Także wszystkie pliki będą dołączane do systemu. Najlepiej będzie stworzyć funkcję, która będzie tworzyła mapę plików: interfejsów, klas i innych. Interfejsy do jednej mapy, klasy do innej a inne wywalić.

Idąc tropem myślenia prostego człowieka, lepiej inkludować jak leci, a nie analizować, czy klasa Ci jest potrzebna czy nie. Zauważ, że moze być sytuacja, ze pare klas dziewdziczy po tym samym obiekcie. Wtedy znowu trzeba dorawiać sprawdzanie czy plik został dołączony i taki wynalazek będzie uruchamiany przez cały dzień.

IMHO. Mapa dla klas, po kolei lecieć z dołączaniem, tworzenie obiektów, osobna mapa na singleton, osobna na interfejsy.

pozdrawiam, Wojtek

Proste pytanie - po co sie tak meczyc ?

Null dla pozniejszej wygody, testowania, itd ;]

Ociu... generalnie zeby dolaczyc klasy po ktorych dziedziczy klasa x, nalezy dostac sie do glownego rodzica, a potem w dol dolaczac pokolei dzieciakow, wiec to jest nieuniknione. W miedzy czasie oczywiscie pokolei rowniesz dolaczac interfejsy Ale to tylko groznie brzmi
Co do sensu... niby mozna by zaladowac wszystkie pliki i darowac sobie... tylko czy zawsze korzystasz, ze wszystkiego? Przy mniejszych i srednich projektach, ok... mozna od biedy wlaczyc te parenascie klas i juz, ewentualnie zaprzegnac __aoutoload i wlaczac w momencie pierwszego pojawienia sie w wywolaniu, ale co jesli masz w systemie dziesiatki plikow? Poza tym zaleta takiego managera jest to, lub moze byc to, ze wiesz kiedy, co i jak, oraz jak dlugo jest wywolywany dany obiekt, czy grupa obiektow.

Nie wydaje mi sie tez by narzut czasowy spowodowany 2-3 petlami przy dolaczaniu dziedziczonych klas byl duzy, ale to chyba musze potestowac.

A co do mapy, moglbys cos dokladniej napisac jak mialo by to wygladac?

Factory ma sens, jesli w kilku miejscach w programie tworzysz obiekty tej samej klasy w nieco odmienny sposob. W twoim scenariuszu widze w zasadzie obiekt tworzony jednokrotnie. Zamiast komplikowac sobie zycie implementujac fabryke, po prostu umiesc kod inicjujacy w konstruktorze.

Przemysl tez czy ma sens tworzenie plikow konfiguracyjnych. Jesli laczysz sie ciagle z ta sama baza, to prosciej jest parametry umiescic w konstruktorze. Wyglada to moze 'nieprofesjonalnie', ale jest znacznie lepszym rozwiazaniem niz dopisywanie kilkudziesieciu linii kodu do obrabiania pliku konfiguracyjnego, z ktorego aplikacja przez 2 lata wczytuje ta sama informacje. Konfig sobie zawsze mozesz 'wypiac' do pliku zewnetrznego jesli bedzie taka potrzeba.