Wpis z mikrobloga

@yelen: skorzystam z okazji, a mianowicie pytanie: zastanawiałem się kiedyś nad tym clean code ale w pracy ludzie mają o tej książce różne opinie. myślisz, że warto się za nią brać czy szkoda czasu?
@yelen: przeczytać jeszcze raz, i jeszcze raz. Tego to chyba nikt nie ogarnia, bo jest sporo gdybania gdzie wsadzić daną klasę, jak co podzielić.

@paleontolog: Zdecydowanie warto.

@yelen: Nie wiesz bo wszystko zależy od konkretnego problemu :) Dla jednej aplikacji wystarczą dwie paczki - jedna na UI i logikę aplikacji i druga na logikę biznesową, inna będzie potrzebować 10 paczek. Może napisz z czym konkretnie masz problem?

A co do DDD to w uproszczeniu jest to sposób na modelowanie dużych systemów ze złożoną logiką biznesową i w kontekście takich systemów DDD powinno być rozpatrywane.
@markaron: O, ktoś kontrenty. Mój problem leży niżej niż moduły. Bardziej chodzi o klasy, jaka, ma jaką odpowiedzialność, czy powinna być zarządzana przez kontener aplikacji, czy powinna zawierać metody biznesowe czy być tylko strukturą danych. Problem też mam taki, żę jak się nie śpieszę w domu to bardzo dużo refaktoruję i WYDAJE MI SIĘ że tak to powinno być. Niekiedy w tym refaktoringu zataczam koła. Jak ostanio byłem na całkiem nieźle
@yelen: > Jak ostanio byłem na całkiem nieźle prowadzonym projekcie to byłem pod wrażeniem tej całej struktury, ale dalej nie wiem z czego ona wynika.

Z doświadczenia.

A co do twojego problemu to zależy od specyficznego problemu. Jeżeli chodzi o odpowiedzialność klas to tak jak jest napisane w Clean Code (rozdział 10 Zasada pojedyńczej odpowiedzialności, s.156) klasa powinna mieć tylko jeden powód do zmiany. Przykładowo klasa posiadająca dwie publiczne metody, jedna
markaron - @yelen: > Jak ostanio byłem na całkiem nieźle prowadzonym projekcie to był...

źródło: comment_tTnsuELCONqMIO29DWseWGn4hh3LXAG7.jpg

Pobierz
@markaron: To co pokazałem to przykład podziału na klasy w warstwie logiki biznesowej. Jak pewnie wiesz wyróżniamy jeszcze inne warstwy (infrastruktury, aplikacji, prezentacji, persystencji inaczej dostępu do danych). W każdej z tych warstw wciąż obowiązuje zasada pojedyńczej odpowiedzialności
@yelen: Z moich odczuć ksiązka Clean Code mówi: "nie pisz w ten sposób, pisz w taki". Brakuje mi w niej wytłumaczenia na żywym kodzie lub w oparciu o dane statystyczne, dlaczego dane rozwiązanie jest lepsze od innego i w jakim stopniu - pod tym względem bardzo polecam http://helion.pl/ksiazki/kod-doskonaly-jak-tworzyc-oprogramowanie-pozbawione-bledow-wydanie-ii-steve-mcconnell,koddos.htm .

Tak jak pisze @markaron staraj się rodzielać odpowiedzialność między klasy. Zwróć uwagę na długość metod oraz pilnuj prawa Demeter, co do wywołań
@yelen: To ja jeszcze od siebie polecę Pragmatic Programmer na początek, moim zdaniem pozycja komplementarna to CC. Na tym etapie DDD wydaje mi się overkillem, warto się za to brać mając już za sobą chociaż jeden większy problem, a Ty piszesz, że masz problem z podziałem na moduły.
Odnośnie projektowania klas i ich odpowiedzialności, a także pisania kodu o poprawnej strukturze, polecam gorąco TDD Larsa Koskella, książka otwiera oczy na wiele