Temat: Częste błędy na diagramach UML dziedziczenie i użycie

Jakub W.:

co to jest "czyste OOP"?

To takie bez np. "friend class" z C++ (mechanizmów dzięki którym można emulować dziedziczenie).

czyli jest to tylko zabieg czysto techniczny (reużycie kody) a nie analityczno projektowy

Ciekawe pytanie.
Nie wiem jakie były motywy twórcy OOP kiedy "tworzył" dziedziczenie...
gdybym miał strzelać - na pewno chciał osiągnąć reusing, izolowanie działającego kodu... czy chciał usprawnić modelowanie, tego nie wiem :)

BTW: drzewo, jako rodzaj grafu, jest najłatwiejsze w analizie.

żartujesz :)

to jaka klasa grafów jest prostsza w analizie ? :-)

mediator ma pewna odpowiedzialność, której nie maja klasy łączone mediatorem, podobni jak fasada czy adapter

Mimo to wciąż uważam, że jedynym sposobem na usunięcie zależności między klasami jest ich przeprojektowanie.

Wprowadzenie nowej klasy niczego nie zmienia - te klasy dalej od siebie zależą, tyle że część logiki została wydzielona do osobnego komponentu (w sumie to nawet zabawny zabieg - projekt bez mediatora jest zły, więc wystarczy okroić istniejące klasy i z tych "cześci" zrobić nową).

Wrzucam, nie wiem po co ;-)
http://en.wikipedia.org/wiki/Mediator_pattern

Link do wypowiedzi

Temat: Częste błędy na diagramach UML dziedziczenie i użycie

Jarosław Ż.:

To takie bez np. "friend class" z C++ (mechanizmów dzięki którym można emulować dziedziczenie).

języki programowanie są implementacją "czystego idealnego OOAD" a nie odwrotnie

czyli jest to tylko zabieg czysto techniczny (reużycie
kody) a nie analityczno projektowy

[..... ]
gdybym miał strzelać - na pewno chciał osiągnąć reusing, izolowanie działającego kodu... czy chciał usprawnić modelowanie, tego nie wiem :)

dziedziczenie (jak i model klas) to klasyfikacja, pierwsza (to chciał osiągnąć autor) była w biologii, wiec dziedziczenie to wyłącznie uogólnienie lub specjalizacja (kwestia kierunku), implementacja dziedziczenia w językach programowania to między innymi reużycie kodu.... jednak formalnie dziedziczenie to domena modeli pojęciowych a nie modeli struktury

Wprowadzenie nowej klasy niczego nie zmienia - te klasy dalej od siebie zależą, tyle że część logiki została wydzielona do osobnego komponentu (w sumie to nawet zabawny zabieg - projekt bez mediatora jest zły, więc wystarczy okroić istniejące klasy i z tych "cześci" zrobić nową).

wprowadzenie nowej klasy zmienia bardzo wiele, np. wprowadzenie dodatkowego adaptera w API oddzielającego konkretna bazę danych (jej tablice i SQLowe zapytania) od otoczenia korzystającego z tych danych, unizależnia reszte świata od zmian modelu relacyjnego tej bazy

Link do wypowiedzi

Temat: Częste błędy na diagramach UML dziedziczenie i użycie

Sebastian M.:

dziedziczenie [...] nie da się emulować agregacją / kompozycją / asocjacją

Tylko, że celem nie powinna być emulacja, a zastąpienie dziedziczenia jakąś "słabszą", nie tak wiążącą relacją.

Sumując - jeśli na etapie projektowania najlepszym rozwiązaniem jest dziedziczenie to należy je zastosować bez wgłębiania się w to, jak będzie wyglądać diagram (o wyglądzie później).

Jeśli wychodzi, że dziedziczenie jest najlepszym rozwiązaniem, to zgadzam się, że należy je wykorzystać.
Po to w końcu ktoś dał nam taką możliwość. Jednak, jeżeli cały projekt jest w porządku, to nigdy nie będzie nam dane oglądać takich diagramów - one po prostu w takich przypadkach nie powstają.

Mechanizm dziedziczenia wprowadzono min. po to, żeby w pewnych sytuacjach, zamiast modyfikować klasę, można było na jej postawie stworzyć nową (dziedziczenie) i w niej coś nowego zaimplementować.

Ciężko mi jest przypomnieć sobie sytuację gdy nie było (sensownej i logicznej) możliwości zastąpienia dziedziczenia innym rodzajem relacji.

Wprowadzenie mediatora nigdy nie jest rozwiązaniem tego problemu

Tylko, że ja nie napisałem, że jest to rozwiązanie problemu, a pierwszy krok ku temu rozwiązaniu.
Odseparowanie tych wszystkich zależności i zagregowanie ich w jednym miejscu często ułatwia podjęcie kolejnych kroków.

i to z bardzo prostego powodu - nie likwiduje, a jedynie ukrywa (na diagramie), powiązania między klasami (tzn. może ukrywać zależności między obiektami a nie konkretnymi klasami).

Ale nie to jest celem tego pierwszego kroku. Nie ukrycie, a zebranie ich wszystkich w jednym miejscu, przyjrzenie się powiązaniom pomiędzy nimi. To pozwala wyciągnąć wnioski, które ułatwiają dalszą refaktoryzację.

Link do wypowiedzi

Temat: Częste błędy na diagramach UML dziedziczenie i użycie

Jakub W.:
Dziedziczenia nie da się zastąpić kompozycją, ani żadną inną relacją.
Tzn. można iść na jakieś kompromisy podczas projektowania, ale to nie zastąpi "stosowania mechanizmów zgodnie z ich przeznaczeniem".

Skoro nie powstają, to dlaczego w ogóle o nich pisałeś ? ;-)

To podeślij proszę model w którym nie użyto dziedziczenia, a który dość ładnie oddaje hierarchię:
Zwierzę, insekt, ptak, kręgowiec, mrówka, bocian, chomik + funkcja double Rozmiar (int wiek)

Odseparowanie tych wszystkich zależności i zagregowanie ich w jednym miejscu często ułatwia podjęcie kolejnych kroków.

Do separowania należało by użyć interfejsow. Na diagramie masz zbiór konkretnych klas.

Ale nie to jest celem tego pierwszego kroku. Nie ukrycie, a zebranie ich wszystkich w jednym miejscu, przyjrzenie się powiązaniom pomiędzy nimi. To pozwala wyciągnąć wnioski, które ułatwiają dalszą refaktoryzację.

To temat na chyba inny artykuł ;)

Link do wypowiedzi

Temat: Częste błędy na diagramach UML dziedziczenie i użycie

Sebastian M.:

Skoro nie powstają, to dlaczego w ogóle o nich pisałeś ? ;-)

Napisałem, że " jeżeli cały projekt jest w porządku, to nigdy nie będzie nam dane oglądać takich diagramów" i dokładnie o to chodzi w moim wpisie. Jeżeli widzisz taki diagram tzn., że warto zastanowić się gdzie mógł wkraść się błąd. W sumie o tym jest cały artykuł.

To podeślij proszę model w którym nie użyto dziedziczenia, a który dość ładnie oddaje hierarchię:
Zwierzę, insekt, ptak, kręgowiec, mrówka, bocian, chomik + funkcja double Rozmiar (int wiek)

Jeżeli celem jest posiadanie metody double Rozmiar(int wiek) to uważasz, że rzeczywiście potrzebuję tutaj dziedziczenia? IMO interfejs jest wystarczający.

Odseparowanie tych wszystkich zależności i zagregowanie ich w jednym miejscu często ułatwia podjęcie kolejnych kroków.

Do separowania należało by użyć interfejsow. Na diagramie masz zbiór konkretnych klas.

Bo gdzieś musi zachodzić powiązywanie wyniesionych zależności? Jakby Twoim zdaniem miał to zrealizować interfejs?

Ale nie to jest celem tego pierwszego kroku. Nie ukrycie, a zebranie ich wszystkich w jednym miejscu, przyjrzenie się powiązaniom pomiędzy nimi. To pozwala wyciągnąć wnioski, które ułatwiają dalszą refaktoryzację.

To temat na chyba inny artykuł ;)

I to pewnie nie jeden :)

Link do wypowiedzi

Temat: Częste błędy na diagramach UML dziedziczenie i użycie

Jakub W.:
Takim podejściem popełniasz IMHO duży błąd - nie możesz oceniać projektu aplikacji bez wiedzy, do czego będzie ona stosowana. Próbujesz ocenić rozwiązanie bez znajomości problemu.

Powiązanie mogłoby zachodzić na poziomie interfejsów. Klasy, zamiast komunikować się ze sobą bezpośrednio (używając konkretnych typów) mogą, na nawet powinny, korzystać z obiektów które implementują konkretny interfejs.

Komunikacja powinna zachodzić na poziomie interfejsu, a nie obiektu konkretnej klasy.

Link do wypowiedzi

Temat: Częste błędy na diagramach UML dziedziczenie i użycie

Sebastian M.:

Jakub W.:
Takim podejściem popełniasz IMHO duży błąd - nie możesz oceniać projektu aplikacji bez wiedzy, do czego będzie ona stosowana. Próbujesz ocenić rozwiązanie bez znajomości problemu.

Taki diagram jest sygnałem, że coś jest nie tak. Chodzi o to, że widząc coś takiego nie "lecisz dalej", tylko zatrzymujesz się i zadajesz pytanie "dlaczego", "jakie były motywy"? Jak to zrobić lepiej? Czy się da? Stwierdzasz, że nie tak powinien wyglądać diagram po samym rysunku, zmieniasz projekt dopiero po zrozumieniu problemu.

Powiązanie mogłoby zachodzić na poziomie interfejsów. Klasy, zamiast komunikować się ze sobą bezpośrednio (używając konkretnych typów) mogą, na nawet powinny, korzystać z obiektów które implementują konkretny interfejs.

Jasne, że powinny. Podsunąłem jednak konkretną propozycję rozwiązania, a czy tego mediatora przedstawisz jako klasę czy interfejs to już sprawa drugorzędna. Ogólnie, tak jak pisałem, powinien to być punkt wyjścia do lepszego rozwiązania, a nie cel podróży.

Link do wypowiedzi

Temat: Częste błędy na diagramach UML dziedziczenie i użycie

Link do wypowiedzi

Temat: Częste błędy na diagramach UML dziedziczenie i użycie

Jakub W.:
Albo nie zmieniasz (bo jest dobry w kontekście zadanej funkcjonalności) :-)

Dlaczego dziedziczenie jest złe ?

Jak oceniasz jakość diagramów (lepsze rozwiązanie) ? Czy masz jakąś konkretną metodę czy robisz to "na oko" ?

Link do wypowiedzi

Temat: Częste błędy na diagramach UML dziedziczenie i użycie

Przemysław W.:
Dzień dobry,

chciałbym prosić o podsumowanie albo krótki przegląd tego tematu.:-)
Ponieważ zaczytam tracić wątek...
Zresztą zrobiło się dużo wątków...

Link do wypowiedzi

Temat: Częste błędy na diagramach UML dziedziczenie i użycie

Sebastian M.:

Dlaczego dziedziczenie jest złe ?

Dziedziczenie nie jest złe. Zbytnio generalizujesz.
Jeżeli jednak powstaje drzewo klas związanych ze sobą poprzez dziedziczenie to IMO coś jest nie tak.

Jak oceniasz jakość diagramów (lepsze rozwiązanie) ? Czy masz jakąś konkretną metodę czy robisz to "na oko" ?

Są rzeczy (m.in. te wspomniane w artykule), które rzucają się w oczy i z dużym prawdopodobieństwem świadczą o tym, że coś w którymś momencie poszło nie tak.

Link do wypowiedzi

Temat: Częste błędy na diagramach UML dziedziczenie i użycie

Jakub W.:

Sebastian M.:
Dziedziczenie nie jest złe. Zbytnio generalizujesz.
Jeżeli jednak powstaje drzewo klas związanych ze sobą poprzez dziedziczenie to IMO coś jest nie tak.

Dziedziczenie nie jest złe, o ile jego stosowanie nie doprowadzi do powstania drzewa hierarchii klas ? :-)

:-) Pora na syntezę....
[...]

Link do wypowiedzi

Temat: Częste błędy na diagramach UML dziedziczenie i użycie

Jakub W.:
A teraz pytanie: co było pierwsze - struktura, czy pojęcie ;-)

Link do wypowiedzi

Temat: Częste błędy na diagramach UML dziedziczenie i użycie

Jakub W.:
Dziedziczenia nie da się zastąpić kompozycją, ani żadną inną relacją.

Link do wypowiedzi

Temat: Częste błędy na diagramach UML dziedziczenie i użycie

Sebastian M.:

Dziedziczenie nie jest złe. Zbytnio generalizujesz.
Jeżeli jednak powstaje drzewo klas związanych ze sobą poprzez dziedziczenie to IMO coś jest nie tak.

Dziedziczenie nie jest złe, o ile jego stosowanie nie doprowadzi do powstania drzewa hierarchii klas ? :-)

Dziedziczenie nie jest złe. W ogóle. To jest jak z każdym innym narzędziem. Efekt końcowy po prostu nie musi być zadowalający/poprawny.

:-) Pora na syntezę....
[...]

Cóż, pozostaje mi zapytać - skąd takie wnioski?

Link do wypowiedzi

Temat: Częste błędy na diagramach UML dziedziczenie i użycie

Jarosław Ż.:

Dziedziczenia nie da się zastąpić kompozycją, ani żadną inną relacją.

nie zastępujemy dziedziczenia kompozycją ale modelujemy daną złożoność jako kompozycje a nie dziedziczenie... to fundamentalna różnica...

innymi słowy: zamiast "dokumentów konkretnych" dziedziczących po "dokumencie ogólnym" (jedna z głupszych konstrukcji jakie widuję) stosujemy konkretne agregaty "dokument konkretny" będące kompozycją cech (struktura dokumentu). Zamiast struktury dziedziczenia faktura, WZ, pismo do prokuratury, dziedziczy po "dokument", tworzymy osobne osobne agregaty (czyli kompozycje) dla każdego typu dokumentu, dzięki temu to nie tworzymy fikcji jakoby WZ miało coś wspólnego z pismem do sądu

Link do wypowiedzi

Temat: Częste błędy na diagramach UML dziedziczenie i użycie

Jakub W.:

Jarosław Ż.:

Dziedziczenia nie da się zastąpić kompozycją, ani żadną inną relacją.

nie zastępujemy dziedziczenia kompozycją ale modelujemy daną złożoność jako kompozycje a nie dziedziczenie... to fundamentalna różnica...

Rozumiem.
Wciąż jednak uważam, że pewne zjawiska (byty) łatwiej / lepiej modelować poprzez dziedziczenie.
Dla przykładu strumienie danych (Streams) / elementy GUI (przyciski, ramki, etc ... ).

Oczywiście można do tego użyć kompozycji, ale gdybym miał wybrać ...

innymi słowy: zamiast "dokumentów konkretnych" dziedziczących po "dokumencie ogólnym" (jedna z głupszych konstrukcji jakie widuję) stosujemy konkretne agregaty "dokument konkretny" będące kompozycją cech (struktura dokumentu). Zamiast struktury dziedziczenia faktura, WZ, pismo do prokuratury, dziedziczy po "dokument", tworzymy osobne osobne agregaty (czyli kompozycje) dla każdego typu dokumentu, dzięki temu to nie tworzymy fikcji jakoby WZ miało coś wspólnego z pismem do sądu

oczywiście, że mają coś wspólnego - można je wydrukować (metodę "drukuj") i zapisać (metoda "zapisz") :-)

.. poprzednie to oczywiście żart :-)

Link do wypowiedzi

Temat: Częste błędy na diagramach UML dziedziczenie i użycie

Jarosław Ż.:

Dziedziczenia nie da się zastąpić kompozycją, ani żadną inną relacją.

nie zastępujemy dziedziczenia kompozycją ale modelujemy daną złożoność jako kompozycje a nie dziedziczenie... to fundamentalna różnica...

Rozumiem.
Wciąż jednak uważam, że pewne zjawiska (byty) łatwiej / lepiej modelować poprzez dziedziczenie.

tu tak, ale to konstruktory takie jak Dekorator :)
też bym wybrał wzorzec Dekorator :), w zasadzie opiera się na dziedziczeniu, tu dziedziczenie użyto jako metode re-użycia kodu

Link do wypowiedzi

Temat: Częste błędy na diagramach UML dziedziczenie i użycie

Jakub W.:
Moim zdaniem dyskusja sprawdza się do tego, czy dziedziczenie może być użytecznym narzędziem modelowania. Moim zdaniem takim jest (przynajmniej w znanych mi dziedzinach) i są na to konkretne przykłady.

Link do wypowiedzi