Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: DI vs Inheritance jeśli idzie o dostęp do danych
Forum PHP.pl > Forum > PHP > Object-oriented programming
trzczy
Kiedy fabryka produkuje sporo obiektów i każdy obiekt musi mieć dostęp do danych, które fabryka posiada, to lepiej Inheritance czy DI?

Załóżmy, że jest klasa fabryki o nazwie Test. I ta fabryka może produkować obiekty o klasie dziedziczącej(1.), albo o klasie pierwotnej z DI(2.):

1.
Kod
class PukProduct extends Factory{
    function __toString() {
        return $this->puk . "<br>\n";
    }
}


2.
Kod
class PinProduct {
    private $pin;

    function __construct($pin)     {
        $this->pin = $pin;
    }

    function __toString() {
        return $this->pin . "<br>\n";
    }
}


Ostatnio coś rozkminiałem i stanąłem przed tym dylematem. W przypadku dziedziczenia (1.) każdy wyprodukowany obiekt powstaje z klasy poszerzonej o klasę źródłową. Jeżeli ta klasa źródłowa jest, załóżmy, wielka to czy taki wyprodukowany obiekt jest tym samym większy od takiego, który powstaje na bazie klasy niedziedziczącej (2.)?

Jeśli jest przez to wielki i występuje wielokrotnie to chyba zajmuje pamięć? Jeśli tak, to nie lepiej stosować samo DI bez dziedziczenia(2.)?
Z góry dziękuję

edit: Poprawiłem tytuł, dostęp "do danych", a nie "di danych"
Skie
Twoje pytanie jakie zadałeś w tym temacie jest nie do końca jasne. Porównujesz użycie dwów wzorców, które stosowane są pod inne potrzeby, a dodatkowo w dość dziwny sposób pokazujesz przykład użycia fabryk w kodzie, co budzi moje podejrzenia, że być może źle je interpretujesz.

Mówiąc krótko, dziedziczenie jest po to, byś rozszerzajać daną klasę nie musiał kopiować kodu z klasy bazowej, a Dependency Injection po to, by kod był prostszy do ponownego użycia i do testowania. DI powinieneś używać zawsze, bo jest to krótko mówiąc dobra praktyka programistyczna, która być może na poczatku trudna (zwłaszcza jak ktoś się przyzwyczaił do Singletonów, Fasad lub programowania opartego o klasy jak sprzed 10lat), po opanowaniu niesie ze sobą same korzyści. Dziedziczenie używasz z kolei wtedy, gdy jest Ci rzeczywiście potrzebne.

Teraz wracając do Twojego pytania, to jeśli pytasz o nadmiarowy kod, który może się pojawić w klasie potomnej ze względu, na to że potrzebujesz założmy tylko 20% klasy funkcjonalności klasy bazowej, to ewidentnie zrobiłeś coś źle z architekturą programu. W innym przypadku jeśli Twoje pytanie sprowadza się tylko do "czy większa klasa = cięższy pamięciowo obiekt?" to odpowiedź brzmi tak.
trzczy
Pytanie w temacie nie jest w kwestii ogólnej, lecz odnosi się do konkretnego przykładu podanego w poście. Chodzi o produkcję takich obiektów, które mają dostęp do danych, danych które posiada produkująca je fabryka. Czy dostęp do tych danych uzyskać przez inheritance, czy przez DI.

Niemniej, mimo pewnej niejasności mego zapytania, za co przepraszam, twoja odpowiedź będzie dla mnie cenną wskazówką.

Architektura jest taka, że w aplikacji MVC klasa View produkuje obiekt klasy Template. Obiekt Template produkuje obiekt klasy CodeParser, który analizuje html-ową templatkę pod kątem miejsc, gdzie trzeba wstawić jakiś powtarzalny fragment kodu lub fragment kodu wygenerowany na podstawie danych z bazy danych.

Dla każdego z tych miejs tworzy obiekt właściwej klasy, np. klasy Footer, Navigation albo Articles itp.

Czyli na końcu łańcuszka może się pojawić taki obiekt Articles, który posiada dane z bazy danych.

Zgodnie z architekturą MVC te dane są dostępne w klasie View. I teraz, czy taki obiekt Articles ma pobierać dane z View przez Inheritance czy przez DI?


edit: literówki i więcej jednoznaczności
com
ale nie można było napisać dziedziczenie co?

No skoro tworzysz klasę innego widoku, to raczej ona jest rozszerzeniem tej bazowej nie?
trzczy
Ok. Zatem rozumiem to przełożenie klasy bazowej na poszczególne widoki. Można też przewidzieć widoki, które w istocie tylko w znikomym stopniu korzystają z zasobów klasy bazowej. Przykładem może być strona z krótką treścią: "Zostałeś zalogowany. Naciśnij ok". Co i tak nie psuje całej idei widoków.

Tylko ja mam trochę inną architekturę. Dane z kontrolera są przypisane do jednej zmiennej $data. Do tych danych załączony jest string, określający szablon widoku, któy to szablon ma być użyty. Ten string szablonu może się nazywać 'index' albo 'articles', albo 'tagListing' czy 'portfolio' itd. Teraz fabryka obiektów bierze konkretny szablon identyfikowany przez taki klucz, potem buduje obiekty dla poszczególnych elementów strony. Np. obiekt footera, obiekt artykułów, headera, sekcji reklam itd.

Po prostu u mnie nie ma całościowego obiektu odpowiadającego za konkretny widok. Jest owszem całościowy obiekt View, ale on jest uniwersalny dla każdego widoku. Są natomiast obiekty poszczególnych części widoku. Teraz te obiekty poszczególnych części widoku muszą mieć dojście do zmiennej $data.

I to dojście chyba jednak powinno być przez DI, a nie przez dziedziczenie, aby uniknąć dziedziczenia zbyt wielu zasobów przez mały obiekt, co mogłoby, o ile się nie mylę, wpłynąć na zwiększone zajmowanie pamięci. Ciekawi mnie aspekt ekonomii pamięci przy wyborze pomiędzy dziedziczeniem, a wstrzyknięciem zależności bez dziedziczenia. Być może problem w ogóle wyssany z palca i nie ma różnicy?
com
Oczywiście, że jak masz n obiektów, które maja dostać te same dane to lepsze wstrzykniecie zależności, niż tworzenie n obiektów, które miały by otrzymać to samo to by było bez sensu i wręcz dziwne jakby miało być inaczej wink.gif
trzczy
Dzięki za dyskusję. Pozdrawiam :-)
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.