Spójność komponentów

przez Karol Bocian | 30 maja, 2020
0 komentarzy

Komponenty

Komponenty to najmniejsze wdrożeniowe elementy oprogramowania, które można instalować.

Spójność komponentów

Spójność komponentów oznacza składanie komponentów takich sposób, aby zachowywały one harmonię oraz były jak najbardziej jednolite. W zapewnianiu spójności komponentów pomagają następujące zasady:

  • REP — Zasada istotności numeru wydania (ang. Reuse/Release Equivalence Principle).
  • CCP — Zasada wspólnego domknięcia (ang. Common Closure Principle).
  • CRP — Zasada wspólnego użycia (ang. Common Reuse Principle).

REP — Zasada istotności numeru wydania (ang. Reuse/Release Equivalence Principle)

Podstawą ponownego użycia komponentu jest jego numer wydania.

Źródło: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin. — s. 124.

Elementy komponentu muszą tworzyć spójną całość, mieć wspólny cel lub przeznaczenie. Numer wydania pozwala zgromadzić ten konkretny stan oprogramowania w spójną całość. Numer wydania informuje o zawartości konkretnej wersji komponentu, kompatybilności komponentów, nowych wersjach i zmianach, które wnoszą.

CCP — Zasada wspólnego domknięcia (ang. Common Closure Principle)

W ramach komponenty zgromadź te klasy, które zmieniają się z tego samego powodu i w tym samym czasie. Na różne komponenty rozdziel te klasy, które zmieniają się w różnym czasie i z różnych powodów.

Źródło: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin. — s. 125.

Zmiana w aplikacji jest nieunikniona. Jeżeli taka ma nastąpić, najlepiej byłoby, gdyby dotyczyła tylko jednego komponentu. Można tutaj zauważyć podobieństwo z zasadą SRP — pojedynczej odpowiedzialności. Obie mówią w skrócie: Grupuj w jednym miejscu elementy, które mają ten sam powód zmiany, a rozdzielaj te, które mają wiele powodów do zmiany (element odpowiada przed wieloma aktorami).

CRP — Zasada wspólnego użycia (ang. Common Reuse Principle)

Nie zmuszaj użytkowników komponentu do zależności od rzeczy, których nie potrzebują.

Źródło: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin. — s. 126.

Klasy, które nie są ze sobą ściśle związane, nie powinny być w tym samym komponencie. Można tutaj zauważyć podobieństwo z zasadą ISP — Zasada segregacji interfejsów. Obie mówią w skrócie, aby nie tworzyć zależności od rzeczy, które są nam niepotrzebne.

Diagram napięć dla spójności komponentów

Zasady spójności komponentów:

  • REP — Zasada istotności numeru wydania (ang. Reuse/Release Equivalence Principle).
  • CCP — Zasada wspólnego domknięcia (ang. Common Closure Principle).
  • CRP — Zasada wspólnego użycia (ang. Common Reuse Principle).

Powyższe zasady są ze sobą sprzeczne, ponieważ REP i CCP są włączające (dążą do dołączania elementów do komponentu), a CRP jest wyłączająca (odrzuca elementy z komponentu). Należy szukać balansu między tymi zasadami.

Źródło: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin. — s. 128 — Rysunek 13.1 Diagram napięć między zasadami spójności komponentów

Na powyższym diagramie przedstawione są relacje między wspomnianymi zasadami. Wszystkie komponenty znajdują się w polu określonym przez trójkąt, którego wierzchołkami są omawiane zasady. Umiejscowienie komponentów zmienia się wraz z rozwojem architektury i aplikacji. Zazwyczaj na początku najważniejsza jest łatwość rozwoju systemu, dlatego komponenty znajdują się blisko zasady CCP, a z czasem komponenty przesuwają się w lewą stroną na rzecz lepszych wydań.

Komponenty będące blisko REP i CRP borykają się z problemem zmieniania się przy każdej drobnej zmianie aplikacji. Komponenty będące blisko CCP i REP mają problem tworzenia zbyt często nowych wydań.

Wszystkie posty związane z mini projektem: Budowa czystej architektury:

Źródła

Obrazy

Materiały

  • Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin.
Kategoria: Projekt Budowa czystej architektury

O Karol Bocian

Programowanie i świat agentów programowalnych, który poznał na Wydziale Matematyki i Nauk Informacyjnych, wciągnął go w przemysł IT. W trakcie swojej praktyki zawodowej Karol zrozumiał, że nie ważne co się robi i kim się jest, ale wiedza z zarządzania przydaje się wszędzie. Rozpoczął studia na kierunku Zarządzanie i Inżyniera Produkcji. W przypadku Karola zarządzanie to nie tylko teoria czy praca, ale prawie każdy element jego życia, to jego pasja.

Zobacz wszystkie wpisy, których autorem jest Karol Bocian →