Przejdź do głównej zawartości

Odkryj Moc Hermetyzacji: Jak Tworzyć Solidne Encje

W świecie programowania obiektowego, termin „hermetyzacja” odgrywa kluczową rolę. Jak Grady Booch, jeden z pionierów programowania obiektowego, określił w swojej książce 'Object-Oriented Analysis and Design':  Hermetyzacja to proces kompartmentalizacji elementów abstrakcji, które stanowią jej strukturę i zachowanie; kompartmentalizacja służy do ukrycia wewnętrznych mechanizmów działania obiektów i ujawniania jedynie tych aspektów, które są zewnętrznie widoczne. To właśnie hermetyzacja wyróżnia dobrze zaprojektowane obiekty od prostych kontenerów danych. Przyjrzyjmy się, jak ten koncept wpływa na projektowanie encji. Problem Encji Anemicznych: Przykład Dostępności W tradycyjnym podejściu anemicznym, encje często są traktowane jako proste kontenery danych. Przykładem może być klasa `Availability`, która przechowuje informacje o dostępności terminu, ale sama w sobie nie zawiera żadnej logiki biznesowej: ```java class Availability {     private LocalDate date;     private boolean i

Odkryj Moc Hermetyzacji: Jak Tworzyć Solidne Encje

W świecie programowania obiektowego, termin „hermetyzacja” odgrywa kluczową rolę. Jak Grady Booch, jeden z pionierów programowania obiektowego, określił w swojej książce 'Object-Oriented Analysis and Design': 

Hermetyzacja to proces kompartmentalizacji elementów abstrakcji, które stanowią jej strukturę i zachowanie; kompartmentalizacja służy do ukrycia wewnętrznych mechanizmów działania obiektów i ujawniania jedynie tych aspektów, które są zewnętrznie widoczne.

To właśnie hermetyzacja wyróżnia dobrze zaprojektowane obiekty od prostych kontenerów danych. Przyjrzyjmy się, jak ten koncept wpływa na projektowanie encji.

Problem Encji Anemicznych: Przykład Dostępności

W tradycyjnym podejściu anemicznym, encje często są traktowane jako proste kontenery danych. Przykładem może być klasa `Availability`, która przechowuje informacje o dostępności terminu, ale sama w sobie nie zawiera żadnej logiki biznesowej:


```java

class Availability {

    private LocalDate date;

    private boolean isAvailable;


    // Getter i setter dla każdego pola

}

```

W tym modelu, wszelka logika związana z zarządzaniem dostępnością musi być implementowana gdzie indziej, co prowadzi do rozproszenia i duplikacji kodu.

## Lepsze Projektowanie Encji: Skupienie na Hermetyzacji

W oparciu o zasadę hermetyzacji Grady'ego Boocha, zrewidujmy nasze podejście do projektowania encji. Dobrze zaprojektowana encja powinna hermetyzować nie tylko swoje dane, ale także zachowania z nimi związane. Weźmy ten sam przykład `Availability` i dodajmy do niego odpowiednie metody:


```java

class Availability {

    private LocalDate date;

    private boolean isAvailable;


    public Availability(LocalDate date) {

        this.date = date;

        this.isAvailable = true; // Domyślnie dostępny

    }


    public LocalDate getDate() {

        return date;

    }


    public boolean isAvailable() {

        return isAvailable;

    }


    public void book() {

        if (!isAvailable) {

            throw new IllegalStateException("Termin jest już zajęty.");

        }

        isAvailable = false;

    }


    public void cancel() {

        isAvailable = true;

    }

}

```

W tej wersji, encja `Availability` nie tylko przechowuje dane, ale także kontroluje logikę ich zmiany. Dzięki temu, obiekt ten staje się pełnoprawnym uczestnikiem w logice biznesowej, co jest zgodne z intencją programowania obiektowego.

## Wnioski

Zrozumienie i stosowanie hermetyzacji w projektowaniu encji to krok w stronę bardziej efektywnego i zgodnego z zasadami programowania obiektowego kodu. Encje, które hermetyzują swoje dane i zachowania, są nie tylko bezpieczniejsze, ale i łatwiejsze do zrozumienia oraz utrzymania. Jest to znacząca zmiana w podejściu w porównaniu do klasycznego modelu anemicznego, która przynosi realne korzyści w procesie tworzenia oprogramowania.


Komentarze

Popularne posty z tego bloga

Współpraca z AI - GPT Engineer

Obawiam się, że szykuje się zagłada Stackoverflow. Już wyjaśniam moje obawy. Do czego zazwyczaj używamy najczęściej StackOverflow? Do rozwiązywania problemów. Nierzadko można tam znaleźć skrypty z gotowymi rozwiązaniami. Okazuje się, że nie ma już potrzeby przeglądania wielu wątków na forum, wystarczy utworzyć odpowiedni opis dla modelu AI, a otrzymamy to co trzeba. No, może nie od razu, ale o tym za chwilę. Pracuję, między innymi, z systemem klasy legacy, który korzysta na froncie z jQuery. Gdzieś w rozmowach pojawiła się potrzeba zrobienia zagnieżdżonego drzewa kategorii z checkboxami o specyficznym zachowaniu. Kiedy słuchałem opisu tego wymagania w głowie układałem już prompt dla GTP,  czy poradzi sobie z tym zadaniem?  Szybko uświadomiłem sobie, że generowanie tego wszystkiego przez webową wersję Chat GPT będzie uciążliwe. Chwilę pogrzebałem w Internecie i znalazłem. GPT Engineer  — narzędzie napisane w pythonie, które wykorzystuje model GPT jako inżyniera-asystenta. Po otrzymaniu

ChatGPT i rysowanie diagramów?

Ostatnio, testując różne możliwości tego kontrowersyjnego, ale jednak genialnego narzędzia, pojawiła się w mojej głowie potrzeba stworzenia diagramu na podstawie wcześniejszej konwersacji. Zastanawiałem się, jak GPT poradzi sobie z podziałem problemu na konteksty i wyodrębnieniem generycznych subdomen. Nawiasem mówiąc, przeprowadzenie pseudo-sesji event stormingowej z ChatGPT zasługuje na osobny wpis. Biorąc pod uwagę szczątkowy opis biznesu, jaki dostał na wejściu, poszło mu całkiem nieźle. Opis dotyczył aplikacji do rezerwacji samochodów z wypożyczalni. Pomijając szczegóły całej rozmowy, otrzymałem taką listę (jak już wspomniałem, opis był bardzo krótki): ReservationsReservationManagement (processes related to car reservations) ClientAuthentication (verifying client identity and driving license details) VehicleFleetFleetManagement (managing vehicles, their availability, and pricing) GenericAvailability (checking vehicle availability in a specific period) CommunicationNotifications (c