GoldenLine
Zaloguj się

konto usunięte

Temat: SOLIDny kod

Prawie dwa lata temu zakończyłem serię o tym jak programować obiektowo, a ponieważ temat został tam jedynie "delikatnie" poruszony zdecydowałem się na kolejną serię wpisów. Tym razem postanowiłem przybliżyć zasady SOLID.
Mam nadzieję, że mi się to udało.

Poniżej zamieszczam link do wpisu ze spisem treści.
Jeżeli znajdziecie czas i zainteresuje Was temat to zapraszam do lektury. Czekam na opinie i krytykę :)

SOLIDny kod
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: SOLIDny kod

SRP

ogólnie OK ale przykład chyba mylący, po drugie szczytem piramidy SRP jest raczej ogólny model MVC czyli:
- komponent (klasa) Model odpowiada tylko ale za całą, za logikę dziedzinową
- komponent V za prezentacje na ekranie
- komponent C za sterowanie całością

i teraz nie będziemy mieli dedykowanej klasy do walidacji danych formularza tylko np. fabryka nie powinna przyjąć złych danych do utworzenia obiektu, jeżeli zaś dane to np. login, to warto stworzyć typ (valueObject) który sam z siebie sprawdza swojej atrybuty.

pisze o walidacji bo to "kontrola" tego czy obiekt dziedzinowy jest poprawny jest odpowiedzialnością Modelu (dziedziny), zaś login to jakaś odpowiedzialnością kontrolera.

Chyba wygodnie jest korzystać (napisać) klasę komponentu View, która po prostu pokaże na ekranie takie pola jakie dostanie w DTO, wtedy do aktualizacji (zmiana pola) będzie jednak klasa Modelu a nie 'coś w GUI"... tak sądze.

Osobiście od pewnego czasu masowo 'eksploatuje" DTO i VaueObject co pozwala sprowadzić 100% projektu do klas, które na początku nie muszą mieć nawet atrybutów by całość dobrze zaprojektować (tu oczywiście wstaną z krzykiem piewcy teorii , że projektu zaczynamy od modelowania danych, owszem ale strukturalne a nie obiektowe ;))
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: SOLIDny kod

Przykłąd z Liskova ;)

nieszczęśliwy przykład bo w części domenowej stosowanie dziedziczenia np. faktur to szukanie kłopotów :)

tu zasada SRP: faktura odpowiada za opis faktu sprzedaży (dane na fakturze) a nie za: przepływ faktury czy za to jak są wyliczane jej dane, nie za to jak wyliczyć VAT, a np. faktura korygująca (są dwie korekta danych stron oraz korekta wpływająca na wysokość VAT).

Za wytworzenie faktury (jakiejkowiek) powinna być odpowiedzialna fabryka, która będzie miała wariantowe scenariusze dla każdego typu faktury, faktura wytworzona to lekki obiekt z danymi, który nie wie jak powstały dane (raczej oddzielamy metody wytwórcze od obiektów).

Generalnie stosowanie dziedziczenia w częsci Model jest bardzo ryzykowne z perspektywy zasady open-close, bo dokumenty mające nawet pierwotnie wiele podobieństw mogą (nie tylko u ustawodawcy( zacząć żyć własnym życiem, własnie zmiany w fakturach, i do tego pojawienie się faktur zaliczkowych to przykład tego, ze dokumenty nie powinny w ogóle być modelowane z użyciem dziedziczenia.

Z doświadczenia mogę powiedzieć, że w części domenowej wszystko ma się prawo rozjechać (w sensie nie mieć ze sobą nic wspólnego) dlatego stosuję zasadę: żadnych abstrakcyjnych bytów w domenie (głownie z uwagi na open-close i stare ale jajre: nigdy nie mów nigdy).
Link do wypowiedziLink

konto usunięte

Temat: SOLIDny kod

Sebastian M.:
Prawie dwa lata temu zakończyłem serię o tym jak programować obiektowo, a ponieważ temat został tam jedynie "delikatnie" poruszony zdecydowałem się na kolejną serię wpisów. Tym razem postanowiłem przybliżyć zasady SOLID.
Mam nadzieję, że mi się to udało.

Poniżej zamieszczam link do wpisu ze spisem treści.
Jeżeli znajdziecie czas i zainteresuje Was temat to zapraszam do lektury. Czekam na opinie i krytykę :)

SOLIDny kod


Dobra, dobra. To samo jest na wiki. :)
Napisz (lepiej) proszę jak projektować aplikacje które spełniają te zasady.
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: SOLIDny kod

Jakub W.:
Napisz (lepiej) proszę jak projektować aplikacje które spełniają te zasady.

większość wzorców projektowych to efekt open/close, dobre praktyki mówią "nie wołaj przodka" (w kwestii dziedziczenia), wąska specjalizacja klas to konsekwencja tych zasad (głownie open/close i separacji interejsów).

jeżeli odpuścimy sobie 'prace na żywioł" tylko będziemy zaczynali od przemyślanej architektury i na samym początku zastrzelimy bazodanowca to będzie OK :)
Link do wypowiedziLink

konto usunięte

Temat: SOLIDny kod

Jarosław Ż.:
Przykład z Liskova ;)
nieszczęśliwy przykład bo w części domenowej stosowanie dziedziczenia np. faktur to szukanie kłopotów :)
Dlatego właśnie taki, a nie inny przykład :) Chodziło właśnie o zademonstrowanie tej problematyczności. Wstępnie miał powstać kolejny wpis, biorąc jednak pod uwagę dyskusję w komentarzach, doszedłem do wniosku, że nie jest już to konieczne.
Z doświadczenia mogę powiedzieć, że w części domenowej wszystko ma się prawo rozjechać (w sensie nie mieć ze sobą nic wspólnego) dlatego stosuję zasadę: żadnych abstrakcyjnych bytów w domenie (głownie z uwagi na open-close i stare ale jajre: nigdy nie mów nigdy).
Podoba mi się takie podejście.
Jeżeli chodzi o domenę i "jestem kuszony" wyniesieniem czegoś wyżej, to staram się tego unikać. Niestety nie jestem do końca pewien czy mógłbym z czystym sumieniem napisać, że nie tworzę żadnych abstrakcji :(
Link do wypowiedziLink

konto usunięte

Temat: SOLIDny kod

Jakub W.:
Napisz (lepiej) proszę jak projektować aplikacje które spełniają te zasady.
To już byłby raczej temat na książkę, a nie na kilka artykułów na blogu :)
Link do wypowiedziLink

konto usunięte

Temat: SOLIDny kod

Sebastian M.:
Jakub W.:
Napisz (lepiej) proszę jak projektować aplikacje które spełniają te zasady.
To już byłby raczej temat na książkę, a nie na kilka artykułów na blogu :)


No dobra, może być kilkanaście (postów na blogu). W tym momencie nie chodzi o formę, a o treść.
A może ... kod wcale nie musi być solid .. dlaczego właściwie kod powinien być "solid" ? Proszę o wytłumaczenie. W końcu publikujesz na ten temat.Ten post został edytowany przez Autora dnia 29.04.14 o godzinie 18:58
Link do wypowiedziLink

konto usunięte

Temat: SOLIDny kod

Jakub W.:
No dobra, może być kilkanaście (postów na blogu). W tym momencie nie chodzi o formę, a o treść.
Chciałbym się za coś takiego zabrać. Żeby jednak miało to ręce i nogi to należałoby poświęcić "trochę" czasu na przemyślenie i zaplanowanie wszystkiego, bo pisanie samego artykułu to zazwyczaj najprostszy etap :)
Obecnie niestety na coś tak złożonego nie będę miał czasu.
A może ... kod wcale nie musi być solid .. dlaczego właściwie kod powinien być "solid" ? Proszę o wytłumaczenie. W końcu publikujesz na ten temat.
Szczerze mówiąc, to mam nadzieję, że seria wpisów daje odpowiedź na Twoje pytanie :)
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: SOLIDny kod

Jakub W.:
dlaczego właściwie kod powinien być "solid" ?

bo wtedy jest tani w utrzymaniu i rozwijaniu....
Link do wypowiedziLink

konto usunięte

Temat: SOLIDny kod

Jarosław Ż.:
Jakub W.:
dlaczego właściwie kod powinien być "solid" ?

bo wtedy jest tani w utrzymaniu i rozwijaniu....

Eh ... no i nici z "męczenia" Sebastiana :)
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: SOLIDny kod

Jakub W.:
Eh ... no i nici z "męczenia" Sebastiana :)

:)
Link do wypowiedziLink

konto usunięte

Temat: SOLIDny kod

Jakub W.:
Eh ... no i nici z "męczenia" Sebastiana :)

Nie wątpię, że jeszcze będziesz miał ku temu niejedną okazję ;)
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

SOLIDny kod




Wyślij zaproszenie do
Anuluj