Comments on: S.O.L.I.D.ne programowanie – część 2, czyli spoufalamy się

By: Koziolek

Koziolek — Thu, 26 Nov 2009 08:32:33 +0000

Niekoniecznie jest tak, że modelowanie rol jest złe. Jeżeli klient stanie się naszym pracownikiem to pomimo, że w realnym świecie jest to jedna osoba to w naszej systemowej rzeczywistości będą to dwa osobne twory. Rzecz w tym, że obiekt w języku opisuje jakiś aspekt obiektu rzeczywistego. Wiele obiektów w języku może opisywać jeden obiekt fizyczny uwzględniając całkowicie inne jego aspekty.
Należy też pamiętać, że opisując problem nazwy klas takie jak robotnik, manager, klient to bardzo abstrakcyjne podejście. W rzeczywistym systemie Kowalski może być robotnikiem w przypadku płacenia pensji i managerem w odniesieniu do linii produkcyjnej. Bardzo dużo zależy od kontekstu.

By: Sławek S.

Sławek S. — Wed, 25 Nov 2009 22:33:46 +0000

Główny problem z dziedziczeniem pojawia się wówczas gdy używamy go do modelowani “ról”. Przykładowo Robotnik i Manager, albo lepiej Klient i Pracownik. Co jeżeli klient z czasem pewien klient stanie się pracownikiem?

Drugi problem gdy mamy kilkustopniową hierarchię dziedziczenia z powodu tego, że modelujemy być zawierający ortogonalne odpowiedzialności. Np rendering i logikę.

Co do getterów i setterów to oczywiśće racja – “dziwne”, że mainstream jakoś się tym nie przejmuje. Jedyne usprawiedliwienie dla getterow/setterow widzę gdy klasa z założenia ma odpowiedzialność bycia tępą paczką danych – jakieś DTO. Tudzież sytuacja – system z natury jest przeglądarką danych.

By: Koziolek

Koziolek — Tue, 17 Nov 2009 19:53:00 +0000

To zależy. Dziedziczenie pozwalana częściową implementację pewnych wspólnych funkcjonalności. Taki przykład. Mamy jakieś moduły UI. Kilka tabelek, które wyświetlają różne dane, ale w ogólności pozwalają na wykonanie tych samych operacji. Sortowanie, usuwanie rekordów, edycja. Jak zaczniemy to pisać to szybko okaże się, że pewne funkcjonalności, po zastosowaniu genericsów, można uwspólnić. Tworzymy wtedy klasę abstrakcyjną i przenosimy tam te uwspólnione elementy. Mamy w ten sposób wzorzec klasy/metody szablonowej.
Często jest też tak, że jakieś obiekty logicznie po sobie dziedziczą np. manager po robotniku, a różnią się szczegółami implementacji jednej metody. Wtedy nie ma sensu dziedziczenie “do góry” przez wyłączenie wspólnego kodu do klasy abstrakcyjnej. Bardziej opłacalne jest dziedziczeni “w dół”, czyli rozszerzenie klasy robotnik i wymiana implementacji jakiejś metody względnie dodanie nowych metod. OCP i SRP świetnie się uzupełniają. Dobre OCP pozwala na prototypowanie kodu i późniejszą jego refaktoryzację. Sam proces refaktoryzacji jest wtedy bardzo przyjemny i stosunkowo szybki.

By: copernic777

copernic777 — Tue, 17 Nov 2009 19:06:08 +0000

Dziedziczenie chyba posiada inny cel niż stosowanie interfejsów i jako takie jedno nie przeczy używaniu drugiego.
Pomijając sytuacje ‘oczywiste’ , chyba lepiej jest wpierw pomyśleć o zastosowaniu kompozycji niż tworzeniu hierarchii klas. Jeśli będzie się trzymać SRP to konieczność używania dziedziczenia powinna być mniejsza.

By: KoziołekWeb » Blog Archive » S.O.L.I.D.ne programowanie – część 4, czyli apartheid

Mon, 16 Nov 2009 16:01:31 +0000

[...] – część 0, czyli wstęp S.O.L.I.D.ne programowanie – część 1, czyli monogamia S.O.L.I.D.ne programowanie – część 2, czyli spoufalamy się S.O.L.I.D.ne programowanie – część 3, czyli podkładamy [...]