2014-06-26 Clean Code Episode 14, Solid Case Study

Po 5 epizodach poruszających kolejne zasady SOLID przyszła kolej na podsumowanie. Poniżej zestawienie zasad z linkami do relacji:

1. Single responsibility principle
2. Open/closed principle
3. Liskov substitution principle
4. Interface segregation principle
5. Dependency inversion principle 

Odcinek sponsorowała firma Seamless, której przedstawiciel - Radek Kozłowski - na początku spotkania przedstawił obszar działalności firmy.

Radek Kozłowski o Seamless. Co robi u nich wujek Bob?!

W podusmowaniu wujek Bob zajmuje się projektem systemu płacowego z epizodu 7. Na podstawie wymagań klienta sporządzono zestaw use case'ów oraz struktur danych opisywanych za pomocą słownika danych (data dictionary). Dodatkowo zidentyfikował 3 aktorów. Na początku designu zajął się modelem use casów z punktu widzenia architektury wysoko poziomowej. Cały proces dość ciężko opisać bez kawałka kodu albo paru rysunków, więc zrobię to minimalistycznie, żeby czasu waszego nie tracić. Celem tego procesu było wydzielenie modułów o pojedynczej odpowiedzialności - SRP. Zasada OCP została zachowana dzięki wydzieleniu interfejsów fabrykujących, dzięki czemu kontrolery nie zależały od konkretnych implementacji use case'ów czy też typów żądań. Zasadę LSP zaprezentował na podstawie potrzeby użycia konkretnego typu, kiedy mamy wiedzę tylko o typie nadrzędnym. W tym wypadku zastosował rzutowanie, zamiast zaśmiecania interfejsu klasy nadrzędnej. ISP zostało przedstawione na przykładzie wcześniej wspomnianych interfejsów fabrykujących, które posiadały metody dla każdego z typów obiektu tworzonego. Sytuację naprawiona dwoma alternatywnymi rozwiązaniami. Pierwsze polega na rozdzieleniu interfejsów a następnie użyciu mniejszych, wymaganych dla danego kontrolera. Drugie rozwiązanie - bardziej dynamiczne - zakłada użycie stringów w celu rozróżnienia na ich podstawie typu potrzebnego obiektu. Zastosowanie DIP wujek pokazał na przykładzie jednego z use case'ów.

SOLID crew of Łódź JUG

Na końcu znalazła się polemika z podcastem 38 na stacku (dostępny tutaj), podczas której wujek Bob wskazuje, że zasady SOLID są jedynie drogowskazem. Często trzeba jakąś złamać, ale należy robić to świadomie. Jest to kolejny sygnał, że zasady są dla ludzi - dobrze je znać, żeby można je było z satysfakcją łamać;)

Na koniec prezentacja małego ficzera na DMCSie - ten dach naprawdę działa!

Schron przeciwatomowy?

Co dalej?

Obecnie organizujemy letnie, luźniejsze JUGi przy piwku. Niebawem pojawi się dokładniejsze info na portalach społecznościowych. Jeśli macie pomysł na prelekcje piszcie na juglodz@gmail.com.

Mobilization

 18 października organizujemy już 4 edycję Mobilization - konferencję skupioną wokół urządzeń mobilnych. Wszystkich zainteresowanych wystąpieniami zapraszamy na call 4 papers. Potrzebujemy również łapek do pomocy (kontakt juglodz@gmail.com). Jest to świetna okazja do poznania wartościowych ludzi oraz firm chętnie przyjmujących programistów.  



PS. Dzięki Pawłowi Włodarskiemu za zdjęcia.

Clean Coders Episode 12 - The Interface Segregation Principle

Nieuchronnie zbliżamy się do końca omawiania zasad SOLID, albowiem za nami już czwarty odcinek tym razem o zasadzie segregacji interfejsów.

1. Single responsibility principle
2. Open/closed principle
3. Liskov substitution principle
4. Interface segregation principle
5. Dependency inversion principle

Dobra frekwencja jak na Wujka Boba - 30 osób

Sponsorem tego odcinka była firma Samsung, która przedstawiła 4 oferty pracy w Łodzi. Polityka firmy nie pozwoliła na podanie widełek płacowych.

Prezentacja firmy Samsung

Co ciekawego w odcinku?

Nie obyło się bez przebierania. Tym razem wujek Bob wystąpił w roli sensei, w swoim dojo. Przedstawił nam projekt systemu obsługującego bankomat i pokazał co dzieje się gdy klasa "wie" za dużo. Co to znaczy wie za dużo? Chodziło głównie o zależności jakie mamy w projekcie, nie obyło się więc bez wspomnień i cofneliśmy się do czasów C. Jedna klasa, wykorzystywana w nieomalże wszystkich elementach systemu była często zmieniana przez co podczas kompilacji przebudowywany był cały projekt, a to trwało wieki.

Na przykładzie bankomatu wujek pokazał nam jak ciężko jest niedopuścić do opisanego wyżej stanu. Oraz, że często w pogoni za doprowadzeniem do zgodności z jedną z zasad SOLID możemy złamać inną (w przykładzie
była to open/close principle).

Wujek Bob zza krzaka

Co zrobić aby obejrzeć następny odcinek:

- najważniejsze to przyjść na spotkanie JUG Łódź
- przekonać swoją firmę do zasponsorowania kolejnego odcinka (60USD) - szczegóły juglodz@gmail.com
- zarejestrować się na naszym meetupie