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

[Zyx]

Pomysł jest kompletnie bez sensu i zaprzecza zarówno idei obiektówki, jak i zasadom projektowania za ich pomocą.

Przedkładaj kompozycję nad dziedziczenie
Moduły wysokopoziomowe nie powinny zależeć od modułów niskopoziomowych. Powinny zależeć od abstrakcji[/b] - Zasada Odwrócenia Zależności

Fajnie, kod frameworka odwołuje się do klas w przestrzeni [i]Webapp, tylko co z tego, kiedy później stwierdzasz: dobra, trzeba napisać testy, a w tych testach nie chcę startować 3/4 systemu, by przetestować 100-linijkową klasę. Przecież jej testowany obiekt może pracować na atrapach. Ups, tylko jak te atrapy tam wstawić, kiedy twórca klasy za bardzo zapatrzył się w dziedziczenie swoją przestrzeń Webapp i tworzy zależności zaszyte na sztywno? Idźmy dalej. Mamy sobie interfejs, implementuje go 5 klas dostarczających różnych wariantów implementacji... zaraz, jakie 5 klas? W Twoim rozwiązaniu mamy klasę bazową i dziedziczenie po Webapp, czyli lipa niemająca nic wspólnego z obiektówką. Jak chcesz dać możliwość rozszerzania, to robisz interfejs i mówisz: "jak chcesz mieć własną implementację, zaimplementuj ten interfejs i będzie OK". Już pomijam fakt, że ponieważ "wszystko odwołuje się do Webapp", nie ma jak nawet powiedzieć systemowi, który wariant wybieramy.

A teraz najlepsze. Opracowujemy zestaw wspólnych komponentów dla wielu projektów. I znowu zaczyna się science-fiction, bo framework mówi: "Nie będziesz miał przestrzeni cudzych przede mną". I o komponentach wielokrotnego użytku możesz zapomnieć.

4. Własne rozwiązania są moim zdaniem zawsze najlepsze, bo dają 100% elastyczności, rozwijanie kodu jest znacznie prostsze i zazwyczaj są lekkie bo nie muszą zakładać upodobań dużej grupy programistów i wszystkich możliwych sposobów wykorzystania

Wszystko to prawda... pod warunkiem, że programista zna się na tym, co robi i umie prawidłowo korzystać z posiadanych narzędzi. Ponieważ korzystasz z komputera, to na pewno gdzieś mieszkasz i na pewno masz do tego miejsca zamieszkania jakieś drzwi. Drzwi zrobić każdy głupi potrafi z desek przy pomocy gwoździ i młotka, tylko czy powierzyłbyś im później bezpieczeństwo swojego mieszkania? Czy uważasz, że takie zbite z desek drzwi są w stanie lepiej zabezpieczyć Twoje mieszkanie, niż drzwi wyprodukowane w specjalistycznej firmie? Niestety, ale chęci do posiadania własnych drzwi to nie wszystko. 99,9% programistów nie ma wystarczających umiejętności i talentu do projektowania (o czasie już nie wspominając), by osiągnąć poziom choćby w połowie tak dobry, jak gotowe rozwiązania.

A Tobie brakuje rzeczy wręcz elementarnej: umiejętności krytycznego spojrzenia na swój pomysł. Jeśli uważasz, że wymyśliłeś coś genialnego, to weź sobie jakieś tabletki na ból głowy, prześpij się i wróć do dyskusji jutro rano. Nie chodzi nawet o to, że zaprzecza on temu, co ludzkość wypracowała przez kilkadziesiąt lat używania obiektówki, ale o to, że uważasz go za coś doskonałego, a to jest najprostsza droga do katastrofy. Nie ma rozwiązań doskonałych. Praktycznie zawsze jest to coś kosztem czegoś. Jeśli nie potrafisz powiedzieć, co tracisz, a co zyskujesz, to prędzej czy później to się na Tobie zemści. Jeśli nie potrafisz dostrzec wad obecnego rozwiązania, czeka je stagnacja, bo spoczniesz na laurach.