piątek, 7 czerwca 2013

Open/closed principle - zastosowanie na poziomie architektury aplikacji oraz metafory wizualne

"Kod powinien być otwarty na rozbudowę jak kwiat lotosu o świcie i zamknięty na zmiany jak kwiat lotosu o zmierzchu" - jako początkujący projektant natknąłem się kiedyś w jednej z książek na takie "Buddyjskie" wyjaśnienie Open/Closed Principle - jednej z zasad SOLID.

Jednak jak w praktyce zastosować tą zasadę? Czy aplikuje się ona jedynie na poziomie Object Oriented Design czy również na poziomie architektury aplikacyjnej?

W najnowszym artykule "Zarządzenie złożonością przez trójpodział logiki – Open/closed principle w praktyce" opublikowanym na łamach programistamag.pl przedstawiłem swoje przemyślenia na temat OCP, w których integruję:

  • ODD, 
  • podstawy podejścia funkcyjnego, 
  • Building Blocks wchodzące w skład Domain Driven Design,
  • architekturę na poziomie aplikacyjnym.


W artykule chciałbym zaproponować Wam swego rodzaju "framework mentalny", który pozwala zmierzyć się ze złożonymi problemami dzieląc logikę na 3 kategorie:

  • stabilną - której kod relatywnie rzadko podlega zmianom
  • domknięcia logiki - które nie polegają zmianom a rozbudowie
  • wybór domknięć - zmiany enkapsulowane w fabrykach (zgodnie z regułą Uncle Boba: "instrukcje switch są dozwolone jedynie w czeluściach fabryk":)

Zatem jest to meta-model, który pozwala na tworzenie modeli problemów zgodnych z OCP. W artykule znajdziecie również propozycję 3 rodzajów wizualizacji graficznej OCP: jedno, dwu i trójwymiarową - w zależności od preferencji kognitywnych...

Artykuł do pobrania (jak zwykle całkowicie za darmo) tutaj: http://bottega.com.pl/artykuly-i-prezentacje

4 komentarze:

Anonimowy pisze...

Miły, lekki i przyjemny, acz porządkujący i poszerzający wiedzę artykuł! Jedyna uwaga (techniczna): PDF-a zrobiono chyba z wersji niepoprawionej (ale zawierającej już uwagi redaktora).

Sławek Sobótka pisze...

Tak, faktycznie wysłałem pdfa po korekcie. Ale sprawdziłem i nie mam niestety wersji po zastosowaniu korekty - podmienię gdy dostanę ją z redakcji.

Anonimowy pisze...

Hej, napisałeś: "Często programowanie obiektowe jest nauczane w naiwny (i błędny) sposób jako separację rzeczowników (klasy) i czasowników (metody)"

Czy mógłbyś rozwinąć myśl? Być może czegoś nie rozumiem, szczególne biorąc pod uwagę późną porę, ale na tę chwilę nie zgadzam się z tezą o błędnym/naiwnym podziale w kontekście przekształcania czynności/metod w "first class citizen". Moim zdaniem taki zabieg jest tu podyktowany ograniczeniem języka (Java). Np. w Pythonie każdy obiekt jest FCC, dlatego tego rodzaju otoczkę można pominąć i tym samym zachować semantykę (nie mówię, że w bezwzględnie każdym przypadku).

Zaryzykowałbym raczej stwierdzenie, że programowanie obiektowe nauczane jest naiwnie przez ignorancję bardziej elastycznych rozwiązań i purytańskie podejście do samego OOP (popadanie w skrajności nie służy nikomu).

PS. Może w tej materii mam nieco inne zdanie, ale dziękuję za świetny blog - wiele się nauczyłem czytając Twoje publikacje.

Marcin.

Sławek Sobótka pisze...

@Marcin

Posłużyłem się skrótem myślowym, który faktycznie bez wyjaśnienia może brzmieć dziwnie. Ale aby go wyjaśnić trzeba by rozpocząć wywód zataczający kręgi wokół różnych podejść, konsekwencji z nich płynących, metodyk analizy, DDD...

Ale rozwinę go nieco podając przykłady podejść:
pisząc o naiwnym podejściu polegającym segregacji rzeczowniki/czasowniki maiłem na myśli podejście, w którym to:
1. "parsujemy" tekst szukając "dużych" (często występujących) rzeczowników
2. "parsujemy" go ponownie szukając "małych" rzeczowników i wrzucamy te małe rzeczowniki do "worków" z fazy 1.
3. ostatni nawrót parsera to wyłapywanie czasowników i doklejanie ich gdzieś do "worków"

Jest to nic innego jak modelowanie struktur danych (z metodami) a nie obiektów.

Przykładowo w DDD skupiamy się na ochranianiu niezmienników w agregatach (hermetycznych grafach obiektów). Najpierw zastanawiamy się, które z "małych" rzeczowników zmieniają się razem i jakie są między nimi reguły, później grupujemy je w roki i na podstawie zachowania (metod) zastanawiamy się czym są te duże "worki" (jakie mają nazwy).

Inne podejście: szukamy zdarzeń w modelu i zastanawiamy się co razem podlega zmianie...

Siłą rzeczy sprowadzam intuicyjny proces do mechanicznej procedury, aby wyjaśnić różnicę; tak na prawdę procesy myślowe przebiegają inaczej.

Temat jest szeroki i być może mówimy o tym samym a problem wynika z inne rozumienia słów-kluczy w tekście. Chętnie podyskutuję przy okazji jakiejś konferencji albo spotkania branżowego.