sobota, 12 lipca 2008

Zasady projektowania obiektowego – part2

Skoro opisałem poprzednio podstawowe zasady projektowania obiektowego (zebrane w książce „Agile Principles, Patterns, and Practices in C#”), to wypadałoby opisać pozostałe ;) Kolejne sześć dotyczą głównie podziału aplikacji na komponenty (czy pakiety, jak kto woli).


Jeszcze zanim przejdę do meritum mała uwaga: przy stosowaniu tych zasad nie ma znaczenia język programowania, czy framework. Mimo iż opisane zostały w książce, w której kod źródłowy był w języku C# to ich pochodzenie (lata '80, '90) jednoznacznie wskazuje, że język C# nie jest z nimi związany. Tak więc czy C#, Java, czy PHP (5) – zasady dają się zastosować, a ich ignorowanie spowoduje te same problemy nie zależnie od języka ;)


Reuse/Release Equivalence Principle (REP)

Treść: Jednostka ponownego użycia jest równoważna jednostce wydania*. (ang: The granule of reuse is the granule of release).

Opis: Zasada ta ma bardziej „polityczny” charakter niż programistyczny. Chodzi w niej o zapewnienie, że ponownie użyty kod będzie utrzymywany (konserwowany) przez autora dla klientów. Jeżeli ktoś korzysta z biblioteki, to oczekuje, że znalezione bug'i będą naprawiane czy dodawane będą takie rozszerzenia, które nie powodują problemów z kompatybilnością. Implikuje to przypuszczenie że można oczekiwać, że starsze wersje będą także utrzymywane, mimo pojawienia się nowych.

Oczekiwania te wymuszają na autorach bibliotek/komponentów:

  • nadawania numerów wersji do wydań komponentów;

  • gromadzenie w jednej bibliotece komponentów używanych razem;

  • pozwolenie użytkownikom na wykorzystanie starszych wersji;

(takie szybkie podsumowanie zrobiłem ;)


* - moje tłumaczenie jest może nie najlepsze, dlatego uwagi do niego są mile widziane ;)


Common Reuse Principle (CRP)

Treść: Przy ponownym użyciu (reuse) komponentu, wszystkie klasy są wykorzystywane razem.

Opis: Celem tej zasady jest zidentyfikowanie klas, które powinny być umieszczone w jednym pakiecie/komponencie. Klasy, które ściśle współdziałają ze sobą, muszą być umieszczone razem w komponencie. Takie klasy powinny być nierozłączne. Ale klasy, które nie są ze sobą powiązane, nie powinny być umieszczane razem.

Trzymanie się tej zasady zmniejsza ilość testów, które trzeba wykonać na klasach klienckich po nowym wydaniu komponentu (wersji).


Common Closure Principle (CCP)

Treść: Komponent nie powinien mieć wielu powodów do zmian. Inaczej: klasy, które zmieniają się razem, powinny być razem.

Opis: Jest to odpowiednik zasady SRP w odniesieniu do pakietów/komponentów. Klasy, które zazwyczaj zmieniają się z tego samego powodu razem, powinny być umieszczone razem w jednym komponencie. Dzięki temu przy ewentualnych zmianach liczba komponentów, które będzie trzeba wydać (release) i testować będzie ograniczona.

Oczywiście „powody do zmian” nie są już na tym samym poziomie co w zasadzie SRP, tylko na bardziej ogólnym.


Acyclic Dependencies Principle (ADP)

Treść: unikaj wszelkich cykli w grafie zależności komponentu.

Opis: Jest to dość oczywista zasada, czasami samo środowisko wymusza ją, gdy nie może sobie poradzić z linkowaniem. Niestosowanie się do tej zasady (gdy jest to możliwe w ogóle) prowadzi do bardzo dużych problemów ze złożeniem programu, który składa się z wielu modułów. Jest to znane pod określeniem „morning-after syndrome”.

Jak rozpoznać wystąpienie ADP? Po prostu moduł pośrednio zależy sam od siebie, przy czym ilość klas „pomiędzy” (w danej gałęzi grafu) nie ma znaczenia.

Tip: rozwiązywanie ADP możliwe jest na parę sposobów, między innymi: zastosowanie zasady DIP, zastosowanie zasady CRP lub zwykła reorganizacja pakietów.


Stable-Dependencies Principle (SDP)

Treść: Twórz zależności w kierunku pakietów stabilnych.

Opis: Zasada ta mówi, że aby pakiet mógł być łatwo rozszerzony/zmieniony, to nie powinien zależeć od niego żaden pakiet stabilny – który bardzo trudno ulega zmianom. W takiej sytuacji wszelkie zmiany musiałyby uwzględniać ten stabilny pakiet, czyli stary interfejs. A to powoduje, że zmiany byłyby trudne do wprowadzenia. Dlatego zawsze powinno się tworzyć zależności do pakietów stabilnych, które z małym prawdopodobieństwem ulegną zmianom.


Stable-Abstractions Principle (SAP)

Treść: Stabilny komponent powinien dążyć do abstrakcyjności.

Opis: Według tej zasady istnieje zależność między stabilnością a abstrakcyjnością. Mianowicie stabilny komponent powinien także być abstrakcyjny, aby jego stabilność pozwalała mu na rozszerzenia/modyfikacje. Abstrakcyjność oznacza składanie się interfejsu z klas abstrakcyjnych. Ale komponent niestabilny powinien składać się z klas konkretnych.

Brak komentarzy: