Eleganckie zastępowanie klas Frameworka Opcje

[pitbull82]

Witam

Tworzę właśnie pewien portal, a przy okazji framework, który ma mi się przydać do dalszych zastosowań. Cały framework ma zastanowić zamkniętą skrzynkę klas w których nie będzie się nic edytowało, a ewentualną zmianę/rozszerzenie funkcjonalności będzie się osiągało poprzez dziedziczenie z klas bazowych/tworzenie nowych klas. Jak na razie wykombinowałem to tak, ze mam katalog system w którym znajduje się cały framework i katalog application/main w którym znajduje się kopia wszystkich klas frameworka i każda klasa (o ile nie wymaga zmiany funkcjonalności) wygląda tak:

Kod

namespace WebApp;

class JakasKlasa extends \Framework\JakasKlasa {
}

Jednocześnie we wszystkich plikach frameworka nie odwołuję się nigdy do przestrzeni Framework tylko zawsze do przestrzeni WebApp dzięki czemu osiągam to co chciałem - dowolna klasa frameworka może zostać w danej aplikacji zmieniona na inną czy to przez dziedziczenie czy to przez napisanie klasy od podstaw.

Minusy tego rozwiązania:

- wymuszam sytuację, że rozszerzenie frameworka musi znajdować się zawsze w przestrzeni WebApp (chociaż to chyba można by ruszyć poprzez ładowanie przestrzeni z plików konfiguracyjnych)
- wymuszam sytuację, że dla każdej klasy frameworka musi istnieć klasa w przestrzeni WebApp nawet jeśli nic szczególnego się w niej nie dzieje tzn. jeśli dziedziczy ona tylko po klasie z framworka

Pytanie do Was - co sądzicie o opisanym rozwiązaniu i czy można się jakoś prosto pozbyć drugiego minusa tzn. tworzenia w zasadzie pustych plików które nic nie wnoszą?

Pozdrawiam

[dariuszp]

No tak tylko zauważ że ładując klasę taką jak np \Application\Db\Mysql można spokojnie np załadować \Application\Db\SuperMysql która dziedziczy po \Application\Db\Mysql (ale nie musi). Autoloader załatwi Ci ładowanie rodziców.
Jak chcesz podmieniać "w locie" klasę na zasadzie wrzucam nowy plik z klasą == jest on ładowany zamiast oryginału" to możesz to spokojnie osiągnąć na 1001 sposobów. Przykładowo tworzysz sobie taki twór:
\Overwrite\Application\Db\Mysql i autloader patrzy za nim ilekroć próbuje załadować jakiś plik. Jeżeli nadpisywanie ma być wielopoziomowe (znaczy klasa Test może być nadpisana przez SuperTest a SuperTest przez SuperTest2 itp...) to można po prostu operować przestrzeniami nazw jak np \ext1\Application\Db\Mysql, \ext2\Application\Db\Mysql. Można zrobić mały "skaner" który Ci wyłapie wszystkie klasy które np implementują interfejs "ZrodloDanych" albo jak sobie takowy nazwiesz, zrobi Ci listę i np zmienisz dostawcę bo masz:
\Application\Db\MySql
\Batman\Db\MySql
\Dariuszp\Db\MySql

I tak piszesz sobie skrypt który skanuje katalog z bibliotekami i robi Ci grupy klas implementujących ten sam interfejs. Tworzy Ci okienko w którym możesz sobie po prostu przełączyć dostawcę i klasę. Po zapisaniu zmian, podmieniany jest jakiś plik konfiguracyjny z którego korzysta autoloader.
I w ten sposób zyskujesz elastyczność, możliwość podmiany dowolnego elementu itp.
I tak jeżeli bazą jest przestrzeń Application to ładując Applicaton\Db\Mysql, autloader odczytuje z pliku konfiguracyjnego info że jest on zamieniony przez \Batman\Db\Mysql i tę klasę załaduje.

Sytuacja jest o tyle fajna że na dobrą sprawę, \Batman\Db\Mysql może ale nie musi dziedziczyć po oryginale. Załadowanie w przypadku dziedziczenia zapewnia Ci autloader więc tutaj dużych problemów nie ma. Nawet jak system padnie z jakiegoś powodu, można usunąć albo ręcznie zmienić plik konfiguracyjny bez usuwania/przenoszenia plików klas żeby przywrócić np oryginał. A implementować interfejs "ZrodloDanych" może każda klasa. Mało tego, jedne klasa może implementować kilka interfejsów więc zyskujemy sytuację gdzie klasa X może być wykorzystana niezależnie w 2 miejscach w systemie.

Nie zgodzę się też że był by problem z dziedziczeniem. \Batman\Db\Mysql może być samodzielną klasą, może też dziedziczyć po \Application\Db\Mysql. Jak mówiłem, nie widzę też powodu by elementy systemu należały do jednej przestrzeni nazw.

Z debugowaniem też nie ma problemów bo backtrace zawsze Ci pokaże plik i nazwę klasy->metody w jakiej masz problem niezależnie od tego czy użytkownik wpisał sobie \Application\Db\Mysql czy \Batman\Db\Mysql.

Ogólnie można myśleć, bawić się, kombinować itp.

PS: Akurat mechanizm w którym w systemie wyłapuje wszystkie interfejsy dla klas a potem "skanuje" cały system robiąc listę bibliotek pogrupowanych wg implementowanych przez nich interfejsów jest częścią mojej pracy magisterskiej. Jej tematem jest modułowy system CMS pod którym kryje się zwykły mechanizm modułów do rozszerzania możliwości CMS'a, mechanizm pluginów pozwalających "podczepić się" pod jakieś akcje w systemie (np User->add możę odpalić Statistic->regStat a Statistic->regStat może odpalić Image->drawGraph) i ten który w skrócie opisałem wyżej, pozwalający na podmianę właściwie dowolnej klasy w systemie na jej odpowiednik wykorzystując autoloader i plik konfiguracyjny do niego generowany przez panel administracyjny aplikacji.

Ten post edytował dariuszp 7.04.2011, 07:33:02