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

Plecam artykuł:

In presented examples it’s all about quick catch design mistakes, without the need to understand the context, which is described by those diagrams.

http://letstalkaboutjava.blogspot.com/2014/12/what-dia...

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

A jeżeli ktoś ma ochotę lub angielski nie jest jego mocną stroną to artykuł jest jeszcze w wersji polskiej:
http://sebastian-malaca.blogspot.com/2014/11/diagram-p... :)

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

Sebastian M.:
A jeżeli ktoś ma ochotę lub angielski nie jest jego mocną stroną to artykuł jest jeszcze w wersji polskiej:
http://sebastian-malaca.blogspot.com/2014/11/diagram-p... :)

Sebastian, czy zdajesz sobie sprawę z tego, w ilu miejscach (u ilu ludzi) sobie tym artykułem nagrabiłeś??:)

Ja z dziedziczeniem w modelach dziedziny "walczę" i prawie zawsze jest foch :)

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

Jarosław Ż.:
Sebastian, czy zdajesz sobie sprawę z tego, w ilu miejscach (u ilu ludzi) sobie tym artykułem nagrabiłeś??:)

Ja z dziedziczeniem w modelach dziedziny "walczę" i prawie zawsze jest foch :)

Jeśli Sebastian sobie tym u kogoś nagrabi, to oznaczać to będzie tylko jedno - trafił na kogoś, z kim ze 100% pewnością NIE CHCIAŁBY współpracować, za dowolnie duże pieniądze, pod dowolnie sławną marką i na dowolnie wysokim stanowisku :)

Dobra robota. Artykuł w sam raz na do porannej kawy na dobry początek dnia - krótki, ale pouczający.Ten post został edytowany przez Autora dnia 08.12.14 o godzinie 08:17

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

Jarosław Ż.:
Sebastian, czy zdajesz sobie sprawę z tego, w ilu miejscach (u ilu ludzi) sobie tym artykułem nagrabiłeś??:)

Chyba nie jest tak źle. Albo moja wiara w ludzi jest większa :P A tak poważnie to chętnie skonfrontuję się z każdym, kto uważa że problemy poruszone w artykule nie są problemami.
Bo cóż może się stać? Co najwyżej nauczę się czegoś nowego :)

Ja z dziedziczeniem w modelach dziedziny "walczę" i prawie zawsze jest foch :)

Ja z dziedziczeniem ogólnie staram się walczyć i przekonywać do tego, że relacje są tym, co powinni preferować. Czasami nawet mi się to udaje :)

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

Sebastian M.:

Jarosław Ż.:
Sebastian, czy zdajesz sobie sprawę z tego, w ilu miejscach (u ilu ludzi) sobie tym artykułem nagrabiłeś??:)

Chyba nie jest tak źle. Albo moja wiara w ludzi jest większa :P A tak poważnie to chętnie skonfrontuję się z każdym, kto uważa że problemy poruszone w artykule nie są problemami.
Bo cóż może się stać? Co najwyżej nauczę się czegoś nowego :)

ja nie podejmę się konfrontacji bo mogę od siebie to samo napisać, co najwyżej mam maly problem z tym, że dwie klasy (komponenty) mogą się wzajemnie do siebie odwoływać, czy taka para w które klasa jest raz usługodawca a raz usługobiorcą....

Ja z dziedziczeniem w modelach dziedziny "walczę" i prawie zawsze jest foch :)

Ja z dziedziczeniem ogólnie staram się walczyć i przekonywać do tego, że relacje są tym, co powinni preferować. Czasami nawet mi się to udaje :)

nie pamiętam, gdzie ale spotkałem się ze "stylem projektowania zorientowanym na agregacje" z całkowitym "nieużywaniem" dziedziczenia (w modelu dziedziny - logika biznesowa) i zresztą tak robię od dłuższego czasu, bo rozumiem, ze (tu mnie popraw ewentualnie) korzystając z bibliotek (frameworkki) używamy dziedziczenia a nie modyfikujemy "oryginału"? (dotyczy raczej komponetnów V i C z wzroca MVC)

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

Jarosław Ż.:
ja nie podejmę się konfrontacji bo mogę od siebie to samo napisać, co najwyżej mam maly problem z tym, że dwie klasy (komponenty) mogą się wzajemnie do siebie odwoływać, czy taka para w które klasa jest raz usługodawca a raz usługobiorcą....

Tak żeby długo nie szukać i zacząć od "dobrego" przykładu - wzorzec Visitor.

nie pamiętam, gdzie ale spotkałem się ze "stylem projektowania zorientowanym na agregacje" z całkowitym "nieużywaniem" dziedziczenia (w modelu dziedziny - logika biznesowa) i zresztą tak robię od dłuższego czasu,

Też staram się tak pisać/projektować kod, aby w jak największym stopniu wyeliminować dziedziczenie, i nie widzę powodu, żeby nie stosować takiego podejścia również w rozwiązaniach technicznych.

A tego nie rozumiem, mógłbyś wyjaśnić co miałeś na myśli?

korzystając z bibliotek (frameworkki) używamy dziedziczenia a nie modyfikujemy "oryginału"?Ten post został edytowany przez Autora dnia 09.12.14 o godzinie 17:27

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

Sebastian M.:
A tego nie rozumiem, mógłbyś wyjaśnić co miałeś na myśli?

korzystając z bibliotek (frameworkki) używamy dziedziczenia a nie modyfikujemy "oryginału"?

może ja źle zrozumiałem... ;): żeby skorzystać ze standardowych bibliotek (one mogą być też ubgrade'owane w przyszłośći) włączamy do swojego kody biblioteki (z planem ich modyfikacji lub rozszerzania) przez dziedziczenie z oryginały a nie przez ich używanie w oryginale czy tak?

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

Jarosław Ż.:
może ja źle zrozumiałem... ;): żeby skorzystać ze standardowych bibliotek (one mogą być też ubgrade'owane w przyszłośći) włączamy do swojego kody biblioteki (z planem ich modyfikacji lub rozszerzania) przez dziedziczenie z oryginały a nie przez ich używanie w oryginale czy tak?

Kiedyś rzeczywiście dziedziczenie było koniecznością. Jednak obecnie coraz częściej twórcy bibliotek umożliwiają korzystanie z nich bez tej nadmiarowej (najsilniejszej) relacji. Wiele zostało przerzucone na wszelkiego rodzaju adnotacje (np. Java). Dzięki temu kod jest w jakiś sposób "uwolniony" od powiązań z biblioteką.
Oczywiście czasami się nie da, ale z tym już trzeba żyć :)

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

Sebastian M.:

Jarosław Ż.:
może ja źle zrozumiałem... ;): żeby skorzystać ze standardowych bibliotek (one mogą być też ubgrade'owane w przyszłośći) włączamy do swojego kody biblioteki (z planem ich modyfikacji lub rozszerzania) przez dziedziczenie z oryginały a nie przez ich używanie w oryginale czy tak?

Kiedyś rzeczywiście dziedziczenie było koniecznością. Jednak obecnie coraz częściej twórcy bibliotek umożliwiają korzystanie z nich bez tej nadmiarowej (najsilniejszej) relacji. Wiele zostało przerzucone na wszelkiego rodzaju adnotacje (np. Java). Dzięki temu kod jest w jakiś sposób "uwolniony" od powiązań z biblioteką.
Oczywiście czasami się nie da, ale z tym już trzeba żyć :)

ok, rozumiem ;) ale to i tak ma chyba miejsce tylko w części pozadomowej kodu?

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

Pozadomowej? To znaczy? Kłopoty ze zrozumieniem mogą wynikać z faktu, że jestem przed drugą kawą :)

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

A ja sobie pozwolę na konstruktywną krytykę.

1. relations over inheritance
To zdanie jest bez sensu - dziedziczenie jest pewną relacją :)
Dodatkowo, dziedziczenie, jako mechanizm czystego OOP, nie da się emulować agregacją / kompozycją / asocjacją choćby ze względu na pola i metody "protected".

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).

"relations over inheritance" nie ma nic wspólnego z zasadą "open for extension and closed for changes", a może prowadzić do jej naruszenia. 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ć.

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

2 . "Often the first step to fix from such a solution is to introduce a proxy classes (take a look at Mediator design pattern)".

Wprowadzenie mediatora nigdy nie jest rozwiązaniem tego problemu 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). Trzeba przyznać - zastosowanie mediatora może poprawić wygląd diagramu, ale o tym później.

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

Sebastian M.:
Pozadomowej? To znaczy? Kłopoty ze zrozumieniem mogą wynikać z faktu, że jestem przed drugą kawą :)

pozadomenowej (kiedywale ten autokorektor ;)))

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

Jakub W.:
A ja sobie pozwolę na konstruktywną krytykę.

1. relations over inheritance
To zdanie jest bez sensu - dziedziczenie jest pewną relacją :)

nie ma relacji w OOAD a są związki, relacje są w ERD

Dodatkowo, dziedziczenie, jako mechanizm czystego OOP, nie da się emulować agregacją / kompozycją / asocjacją choćby ze względu na pola i metody "protected".

co to jest "czyste OOP"?

agregacja niczego nie "emuluje", rzecz w tym, że zamiast tworzyć konstrukcję "Syrenka i Polonez dziedziczy po Samochód' tworzymy klasę Samochód z klasą skomponowana mająca atrybuty Marka (i np. producent)

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).

dziedziczenie rzadko kiedy jest najlepszym rozwiązaniem w modelowaniu rzeczywistości (która z natury rzeczy nie ma abstrakcji), czyli w tworzeniu modelu dziedziny, bo model dziedziny to nie jest model pojęciowy (gdzie dziedziczenie jak najbardziej ma sens)

"relations over inheritance" nie ma nic wspólnego z zasadą "open for extension and closed for changes", a może prowadzić do jej naruszenia. 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ć.

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

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

żartujesz :)

2 . "Often the first step to fix from such a solution is to introduce a proxy classes (take a look at Mediator design pattern)".

Wprowadzenie mediatora nigdy nie jest rozwiązaniem tego problemu 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). Trzeba przyznać - zastosowanie mediatora może poprawić wygląd diagramu, ale o tym później.

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

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

Jarosław Ż.:
nie ma relacji w OOAD a są związki, relacje są w ERD

Nie ma "relacji" w ERD w tym sensie. Są to związki (relationships).
Relacje są reprezentowane przez tabele (encje).Ten post został edytowany przez Autora dnia 11.12.14 o godzinie 10:11

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

Adrian O.:

Jarosław Ż.:
nie ma relacji w OOAD a są związki, relacje są w ERD

Nie ma "relacji" w ERD w tym sensie. Są to związki (relationships).
Relacje są reprezentowane przez tabele (encje).

Miałem na myśli to, że dwie encje połączone linią na diagramie ERT to trwały zdefiniowany związek tych "encji"

na diagramie klas taka linia pomiędzy dwiema klasami oznacza związek logiczny, a jaki to zależy od kontekstu: na modelu pojęciowym jest to wyłącznie związek pojęciowy (np. w słownik mamy pojęcie faktura i zamówienie i są ze sobą związane pojęciowo bo faktura powstaje w odpowiedzi na zamówienia ale nie jest to to samo co "obiekt faktura jest trwale powiązany z zamówieniem".

na diaggramie ERD połączenie związkiem np. jeden do jednego dwóch encji o tyzh nazwa, oznacza, że takie dwa zapisy są w bazie trwałe połączone (np. kluczem głównym) i ta logika jest " trwale" w tej bazie wpisana.

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

Dokładnie tak :) Chodziło mi tylko o prawidłowe użycie terminu "związki" zamiast "relacje" na ERD.

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

Adrian O.:
Dokładnie tak :) Chodziło mi tylko o prawidłowe użycie terminu "związki" zamiast "relacje" na ERD.

niestety tłumaczenia a nasz język są takie jakie są ;) i budzą wiele nieporozumień dlatego unikam słowa 'relacje" przy okazji UML :)

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

Jarosław Ż.:

A ja sobie pozwolę na konstruktywną krytykę.

1. relations over inheritance
To zdanie jest bez sensu - dziedziczenie jest pewną relacją :)
Dodatkowo, dziedziczenie, jako mechanizm czystego OOP, nie da się emulować agregacją / kompozycją / asocjacją choćby ze względu na pola i metody "protected".

co to jest "czyste OOP"?

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

"relations over inheritance" nie ma nic wspólnego z zasadą "open for extension and closed for changes", a może prowadzić do jej naruszenia. 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ć.

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 ? :-)

2 . "Often the first step to fix from such a solution is to introduce a proxy classes (take a look at Mediator design pattern)".

Wprowadzenie mediatora nigdy nie jest rozwiązaniem tego problemu i to z bardzo prostego powodu -[...] - zastosowanie mediatora może poprawić wygląd diagramu, ale o tym później.

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

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

Jakub W.:
A ja sobie pozwolę na konstruktywną krytykę.

Na taką jestem zawsze chętny :)

1. relations over inheritance

Masz rację, miało być "composition over inheritance". Już poprawione. Dzięki za czujność.

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. A to zawsze przynosi korzyść - zamieniamy najmocniejszą relację, na lżejszą zależność,

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

Nie rozumiem jak to zdanie odnosi się do kontekstu, czyli do poprawnego projektowania rozwiązań?

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ę.