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]

+ nie trzeba robić jakiś pustych klas bóg wie po co i wprowadzać bałaganu
+ nie jesteś ograniczony do jednej przestrzeni nazw. Jak bym tak zarządzał klasami jak autor to przy dzisiejszym rozmiarze mojego FW pewnie bym już nie wiedział co się z czym je biorąc pod uwagę jak się rozrosła
+ nie ma problemów z wyodrębnianiem fragmentów aplikacji i ich testowaniu (z automatu)
+ mam zagwarantowane to że łatwo dorzucę zewnętrzny kod który stosuje się do PSR-0 a tego coraz więcej.
+ nie muszę bezsensownie dziedziczyć po klasie X jeżeli nie ma ku temu faktycznej potrzeby
+ operując przestrzeniami nazw z głową i "sposobem" możemy w dowolnym momencie wymienić dowolny element aplikacji bez jakiś wygibasów

Dlatego mówię że odgórne założenie jest kiepskie bo sprawia więcej problemów jak rozwiązuje. Chyba że czegoś nie załapałem.

Ten post edytował dariuszp 6.04.2011, 16:08:06