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

[Crozin]

1. I chcąc dodać nową implementację musiałbym i tak modyfikować kod owego kontrolera. Zresztą jeżeli na etapie projektowania już wychodzi Ci, że musisz tworzyć obejścia przy tak błahym problemie to pierwszy znak, że coś zrypałeś.
2. Ale pozostaje te 10% i wypadałoby umożliwić jakiś ludzki mechanizm zarządzania tym.
3. Tak, źle zrozumiałeś ideę. Tutaj możesz przeczytać o ogólnej idei: http://symfony.com/doc/2.0/book/service_container.html
4. Najpierw piszesz o 90% stałego kodu, teraz o elastyczności. Z reguły są proste, a proste nie może być elastyczne. Następnie piszesz, że są ociężałe bo starają się obsłużyć wszystkie możliwe sposoby wykorzystania, czyli na dobrą sprawę są elastyczne. Zresztą lekkość nie ma za wiele wspólnego z obszernością kodu. Trochę nie trzymają się Twoje poglądy kupy. Aaa... i w przypadku własnego kodu dolicz kilkaset / klika tysięcy godzin na napisanie tego.