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

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 (communication between the rental company and clients, e.g., sending confirmations and notifications)

Pomyślałem, że miło byłoby mieć to wszystko rozrysowane. Poprosiłem więc o przedstawienie diagramu w postaci tekstowej. Otrzymałem coś takiego:



Nieźle jak na model językowy, jednak mało czytelne. Chciałem uzyskać coś bardziej na kształt mapy kontekstów. Napisałem więc tę sugestię i otrzymałem zmieniony diagram:


Co do sposobu relacji pomiędzy subdomenami można mieć oczywiście zastrzeżenia, ale tak jak już wspominałem, opis systemu był dosyć ubogi, więc GPT miało zdecydowanie za mało informacji na sensowną "analizę". W każdym razie, otrzymałem jakiś diagram. Myśląc jednak o praktycznym podejściu, czy taki diagram rzeczywiście jest czytelny? Jesteśmy raczej przyzwyczajeni do rysowanych prostokącików i strzałeczek... Wtedy przypomniałem sobie o pewnym narzędziu. Mermaid (https://mermaid.live/) — aplikacja do rysowania diagramów zapisanych w specjalnym, całkiem intuicyjnym, tekstowym formacie. Nie pozostało mi nic innego jak poprosić AI o przepisanie diagramu do odpowiedniego formatu.

zapisz diagram w formacie dla Mermaid


Otrzymałem następujący kod:

graph TD
  Reservations[Reservations] -->|Open Host| VehicleFleet[VehicleFleet]
  Reservations -->|Shared Kernel| ReservationManagement[ReservationManagement]
  ReservationManagement -->|Customer| ClientAuthentication[ClientAuthentication]
  ClientAuthentication -->|Shared Kernel| Communication[Communication]
  Communication -->|Shared Kernel| GenericAvailability[GenericAvailability]

  VehicleFleet -->|Shared Kernel| FleetManagement[FleetManagement]
  FleetManagement -->|Customer| Notifications[Notifications]
  Notifications -->|Shared Kernel| GenericAvailability



Po wklejeniu w szybki podgląd na https://mermaid.live/edit otrzymałem taki rysunek:





Pomijając merytoryczne błędy w podziale domen, wygląda to już całkiem ciekawie. Powyższy diagram powstał jednak po odrobinę dłużej rozmowie i nakierowaniu GPT na podział aplikacji na konteksty. Postanowiłem spróbować zadziałać bardziej bezpośrednio. Dałem AI kolejne zadanie:

Na podstawie tylko opisu aplikacji stwórz diagram obrazujący
proces rezerwacji samochodu. 

Odpowiedź:

graph LR
  A[Wybierz samochód] --> B[Wybierz daty rezerwacji]
  B --> C[Podaj dane osobowe]
  C --> D[Podaj dane o prawie jazdy]
  D --> E[Wybierz dodatkowe opcje]
  E --> F[Sprawdź i zatwierdź rezerwację]
  F --> G[Otrzymaj potwierdzenie rezerwacji]

Efekt:



No... proces. Spróbowałem więc trochę podrasować ten graf:

@ja: przerób ten diagram na diagram sekwencji uwzględniający odpowiednich aktorów i potrzebne elementy

@ChatGPT:

sequenceDiagram
  participant Klient
  participant Aplikacja
  participant Wypożyczalnia
  Klient->>Aplikacja: Wybierz samochód
  Aplikacja->>Klient: Pokaż dostępne samochody
  Klient->>Aplikacja: Wybierz daty rezerwacji
  Aplikacja->>Klient: Potwierdź dostępność
  Klient->>Aplikacja: Podaj dane osobowe
  Klient->>Aplikacja: Podaj dane o prawie jazdy
  Klient->>Aplikacja: Wybierz dodatkowe opcje
  Aplikacja->>Klient: Pokaż podsumowanie rezerwacji
  Klient->>Aplikacja: Zatwierdź rezerwację
  Aplikacja->>Wypożyczalnia: Nowa rezerwacja
  Wypożyczalnia->>Aplikacja: Potwierdź rezerwację
  Aplikacja->>Klient: Otrzymaj potwierdzenie rezerwacji


Wygenerowany diagram:


W rezultacie, dzięki współpracy z GPT, udało się stworzyć różnorodne diagramy, które przedstawiają zarówno podział domen, jak i proces rezerwacji samochodu. Oczywiście, wyniki nie są doskonałe, ale są na tyle czytelne i interesujące, że można się zainspirować i kontynuować pracę nad nimi w dalszej rozmowie z AI, lub programie przeznaczonym do tworzenia diagramów.

To doświadczenie pokazuje, że AI może być pomocne w generowaniu wstępnych wersji diagramów oraz wizualizacji, nawet jeśli nie są one idealne.

Moja zabawa z ChatGPT trwa, zobaczę czym jeszcze będzie potrafił mnie zaskoczyć...

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

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