Jak projektować projekty obiektowe? [zamknięte]

Nie mam jeszcze wystarczającej reputacji, aby komentować (dołączył dzisiaj) lub po prostu skomentować odpowiedź Scotta Daviesa. Dodając do tego co miał do powiedzenia:

1. Upewnij się, że wiesz, o co chodzi w twoim programie, zanim zaczniesz. Czym jest twój program? Czego nie zrobi ? Jaki problem próbuje rozwiązać?

2. Pierwszym zestawem przypadków użycia nie powinna być lista Pralnia wszystko program ostatecznie zrobić. Zacznij od najmniejszy zestaw przypadków użycia, które możesz wymyślić, nadal oddaje istotę tego, do czego służy Twój program. W przypadku tej strony internetowej, na przykład, podstawowe przypadki użycia mogą być Zaloguj się, Zadaj pytanie, odpowiedz na pytanie i Zobacz pytania i odpowiedzi . Nic o reputacji, głosowaniu lub wiki społeczności, tylko surowa esencja tego, co robisz.

3. Kiedy wymyślasz potencjalne klasy, nie myśl o nich tylko w kategoriach tego, jaki rzeczownik reprezentują, ale jakie mają obowiązki. Odkryłem, że jest to największa pomoc w zrozumieniu, jak zajęcia odnoszą się do siebie podczas wykonywania programu. Łatwo jest wymyślić relacje takie jak "pies jest zwierzęciem" lub " szczeniak ma jedną matkę."Zazwyczaj trudniej jest ustalić relacje opisujące interakcje między obiektami w czasie rzeczywistym. Algorytmy Twojego programu są co najmniej tak samo ważne jak twoje obiekty i są o wiele łatwiejsze do zaprojektowania, jeśli napisałeś, co każdy z nich praca klasy jest.

4. Gdy już masz ten minimalny zestaw przypadków użycia i obiektów, rozpocznij kodowanie. Zdobądź coś, co faktycznie działa tak szybko, jak to możliwe, mimo że nie robi wiele i prawdopodobnie wygląda jak gówno. To punkt wyjścia i zmusi cię do odpowiedzi na pytania, które możesz przesłać na papier.

5. Teraz wróć i wybierz więcej przypadków użycia, napisz, jak będą działać, zmodyfikuj model klasy i napisz więcej kodu. Podobnie jak twoje pierwsze cięcie, Weź na siebie tak mało w czas, jak możesz, jednocześnie dodając coś znaczącego. Spłukać i powtórzyć.

Tylko moje dwa centy. Mam nadzieję, że się przyda.

Kiedy miałem okazję, zwykle używam czegoś, co nazywam "regułą trzech iteracji".

W pierwszej iteracji (lub uruchomieniu) opracowuję ogólny układ aplikacji zgodnie z obiektami modelu, algorytmami i oczekiwanymi (naprawdę oczekiwanymi, a nie Może oczekiwanymi) przyszłymi kierunkami. Nie piszę dokumentów projektowych, ale jeśli muszę koordynować Wiele osób, potrzebny jest oczywiście szkic procedury wraz z analizą zależności i zgadywanie potrzebnego czasu. Spróbuj ograniczyć ten etap do minimum, jeśli, tak jak ja, wolisz bardziej zwinną metodę. Istnieją przypadki, w których potrzebna jest silna Faza projektowania, w szczególności gdy wszystko jest znane i prawdziwe na temat logiki programu i jeśli planujesz mieć wiele interakcji między funkcjami w kodzie. W takim przypadku przypadki użycia lub historie użytkowników stanowią dobry pomysł na wysokim poziomie, w szczególności w przypadku aplikacji GUI. Dla aplikacji wiersza poleceń, a w szczególności bibliotek, spróbuj napisać "historie programów", w których kodujesz z biblioteką, musisz opracować i sprawdzić, jak wygląda. Programy te staną się testami funkcjonalnymi biblioteki po zakończeniu.

Po tej pierwszej iteracji, będziesz miał lepsze zrozumienie, jak rzeczy współdziałają, wyciągnął szczegóły i szorstkie plamy, rozwiązał problemy z plastrem taśmy klejącej. Jesteś gotowy, aby wykorzystać to doświadczenie, aby poprawić, oczyścić, polerować, podzielić to, co było zbyt duże, połączyć to, co było zbyt rozdrobnione, Definiuj i używaj wzorców projektowych, analizuj wąskie gardła wydajności i nietrywialne kwestie bezpieczeństwa. Ogólnie rzecz biorąc, wszystkie te zmiany będą miały ogromny wpływ na testy jednostkowe, które napisałeś, ale nie na testy funkcjonalne.

Kiedy ukończysz tę drugą iterację, będziesz miał mały klejnot, dobrze przetestowany, dobrze udokumentowany i dobrze zaprojektowany. Teraz masz zarówno doświadczenie, jak i kod do wykonania trzeciej iteracji, extend. Dodasz nowe funkcje i przypadki użycia, aby ulepszyć swoją aplikację. Ty znajdziesz szorstkie plamy i ostatecznie wejdziesz do czwartej iteracji, która jest analogiczna do drugiej. Spłukać i powtórzyć.

Oto moje ogólne podejście do projektowania oprogramowania. Jest on podobny do spiral design, z krótkimi, trzymiesięcznymi iteracjami i elementami zwinnego rozwoju, który pozwala poznać problemy i poznać swoje oprogramowanie i jego obszar zastosowania. Oczywiście jest to kwestia skalowalności, więc jeśli aplikacja jest tak duża, aby zaangażować setki programistów, rzeczy są nieco bardziej złożone niż to, ale w końcu myślę, że pomysł jest zawsze ten sam, podzielić et impera .

Tak podsumowując:

W pierwszej iteracji poznasz jej smak i nauczysz się]} W iteracji drugiej oczyścisz swój produkt i przygotujesz go na przyszłość.]}
1. w iteracji trzeciej dodajesz nowe funkcje i dowiadujesz się więcej
2. goto 2

Najciekawsze źródło jakie znam na ten temat to część D Object Oriented Software Construction, 2nd Edition Autor: Bertrand Meyer

Część D: Metodologia zorientowana obiektowo: zastosowanie metody well

19: 00, 20: Design wzór: multi-Panel interaktywny systemy, 21: studium przypadku dziedziczenia: "Cofnij" w systemie interaktywnym, 22: Jak znaleźć Klasy , 23: Zasady projektowania klas, 24: używanie 25.05.2012, 22: 25 techniki, 26: poczucie stylu, 27: Analiza obiektowa, 28: The proces budowy oprogramowania, 29: Nauczanie metody

Co ciekawe, Rozdział 22. Jak znaleźć zajęcia jest dostępny w Internecie.

To często powtarzane, ale całkowicie prawdziwe-Zrozum swoje dane.

Dla OOP twoje zajęcia powinny opisywać istotne informacje i sposób ich interakcji.

Jeśli masz model mentalny, który dobrze opisuje zachowanie i żywotność danych, będziesz miał łatwą jazdę, układając swoje zajęcia.

To jest po prostu rozszerzenie: wiedz dokładnie, co próbujesz zrobić.

Spróbuj użyć behavior driven development. Trudno będzie przełamać stare nawyki, ale odkryłem, że BDD naprawdę jest najlepszym rozwiązaniem, jeśli chodzi o rozwój w prawdziwym świecie.

Http://behaviour-driven.org/

Problem z dużymi projektami polega na tym, że nie można nadzorować wszystkich interakcji między komponentami. Dlatego ważne jest zmniejszenie złożoności projektu. Diagramy klas i sekwencji są zbyt szczegółowe dla tej fazy projektowania.

Najpierw spróbuj myśleć z wyższego poziomu abstrakcji. Pomyśl o głównych komponentach i ich obowiązkach( ich interfejsie z innymi komponentami), spójrz na niektóre wzorce architektoniczne dla inspiracji (Nie, Nie wzorce projektowe, są zbyt niskie poziom! MVC i Multi-Tier są przykładami wzorców architektonicznych). W przypadku dość dużych projektów taki widok powinien mieć około 3-5 elementów.

Dopiero wtedy powiększasz określony komponent i próbujesz go zaprojektować. Teraz jesteśmy na poziomie wzorców projektowych i diagramów klas. Spróbuj skupić się na tej części projektu, jeśli okaże się, że potrzebujesz dodać odpowiedzialność do jednego z innych komponentów, po prostu dodaj ją do swojej dokumentacji/ listy zadań. Nie trać czasu na myślenie o konsekwencjach w tym momencie zmieniają się zbyt szybko, przeglądając, gdy projekt jest bardziej solidny.

Nie musisz w pełni projektować każdego komponentu w tym momencie, chociaż prawdopodobnie rozsądne jest posiadanie kawałka kodu, który implementuje interfejs nie implementowanych komponentów i generuje proste, ale przydatne odpowiedzi. W ten sposób można rozpocząć rozwój (i projektowanie) jednego komponentu na raz i przetestować go w rozsądnym stopniu.

Oczywiście po skompletowaniu nowych komponentów należy sprawdzić jak (i jeśli) integrują się ze sobą przed pójściem dalej.

W bardzo krótkim: Weź OO i zasady ukrywania informacji, i wyciągnąć go na kolejny poziom!

PS: Zrób dużo szkicowania podczas projektowania, to tak jak prawdziwa Architektura!

PPS: staraj się podchodzić do sprawy z różnych stron, myśl nieszablonowo (chociaż pudełko może być drogą), dyskusja z rówieśnikami może być bardzo przydatna do tego... i masz o czym pogadać przy lunchu.

Wzorce Projektowe

Kreacyjne Wzorce Projektowe

Singleton-zapewnia, że zostanie utworzona tylko jedna instancja klasy i zapewnia globalny punkt dostępu do obiektu.

Factory (uproszczona wersja metody Factory)- tworzy obiekty bez ujawniania logiki instancji klientowi i odnosi się do nowo powstałego obiektu poprzez wspólny interfejs.

Metoda Factory-definiuje interfejs do tworzenia obiektów, ale niech podklasy do zdecyduj, którą klasę utworzyć instancję i odwołuje się do nowo utworzonego obiektu poprzez wspólny interfejs.

Abstract Factory-oferuje interfejs do tworzenia rodziny powiązanych obiektów, bez jawnego określania ich klas.

Builder-definiuje instancję do tworzenia obiektu, ale pozwala podklasom decydować, którą klasę utworzyć i pozwala na lepszą kontrolę nad procesem budowy.

Prototype-określa rodzaje obiektów do utworzenia za pomocą prototypowej instancji i tworzyć nowe obiekty kopiując ten prototyp.

Behawioralne Wzorce Projektowe

Łańcuch odpowiedzialności-unika przywiązania nadawcy żądania do jego odbiorcy, dając w ten sposób innym obiektom możliwość obsługi żądania. - Obiekty stają się częścią łańcucha i żądanie jest wysyłane z jednego obiektu do drugiego w całym łańcuchu, dopóki jeden z obiektów go nie obsłuży.

Command-Enkapsulate żądanie w obiekcie, Umożliwia parametryzację klientów z różnymi żądaniami i umożliwia zapisywanie żądań w kolejce.

Interpreter-dany język, definiuje reprezentację dla jego gramatyki wraz z interpreterem, który używa reprezentacji do interpretacji zdań w języku / mapowania domeny do Języka, Języka do gramatyki, a gramatyki do hierarchicznego projektu obiektowego

Iterator-zapewnia możliwość dostępu do elementów obiektu agregowanego sekwencyjnie bez ujawniania jego podstawowej reprezentacji.

Mediator-Definiowanie obiektu, który zawiera w sobie sposób, w jaki zbiór obiektów oddziałuje na siebie. Mediator Promuje luźne sprzężenie, powstrzymując obiekty od wyraźnego odniesienia się do siebie i pozwala zmieniać ich interakcję niezależnie.

Observer-definiuje zależność od jednego do wielu obiektów tak, że gdy jeden obiekt zmieni stan, wszystkie jego zależności są powiadamiane i aktualizowane automatycznie.

Strategia-Zdefiniuj rodzinę algorytmy, enkapsulują każdy z nich i czynią je wymiennymi. Strategia pozwala algorytmowi różnić się niezależnie od klientów, którzy go używają.

Metoda szablonowa-definiuje szkielet algorytmu w operacji, odkładając niektóre kroki na podklasy / metoda szablonowa pozwala podklasom przedefiniować pewne kroki algorytmu bez pozwalania im na zmianę struktury algorytmu.

Visitor-reprezentuje operację do wykonania na elementach struktury obiektu / Visitor pozwala zdefiniować nową operację bez zmiany klas elementów, na których ona działa.

Null Object-podaj obiekt jako surogat za brak obiektu danego typu. / Wzorzec obiektu Null zapewnia inteligentne zachowanie nie rób nic, ukrywając szczegóły przed współpracownikami.

Strukturalne Wzorce Projektowe

Adapter-konwertuje interfejs klasy na inny interfejs, którego oczekują klienci. / Adapter pozwala klasom współpracować, że nie mógł inaczej z powodu niekompatybilnych interfejsów.

Bridge-komponuje obiekty w struktury drzewiaste, aby reprezentować hierarchie częściowo-całe. / Composite pozwala klientowi traktować poszczególne obiekty i kompozycje obiektów jednolicie.

Composite-komponuje obiekty w struktury drzewiaste, aby reprezentować hierarchie częściowo-całe. / Composite pozwala klientowi traktować poszczególne obiekty i kompozycje obiektów jednolicie.

Dekorator-dodawanie dodatkowych obowiązków dynamicznie do obiekt.

Flyweight-use sharing to support a large number of objects that have part of their internal state in common where the other part of state can vary.

Memento-przechwytuje wewnętrzny stan obiektu bez naruszania enkapsulacji, zapewniając w ten sposób średnią dla przywrócenia obiektu do stanu początkowego w razie potrzeby.

Proxy-provide a "Placeholder" for a object to control referations to it.

Technika, którą stosuję w prawdziwych projektach z rozsądnym powodzeniem, to Responsibility Driven Design, inspirowana książką Wirfs-Brocka.

Zacznij od historii użytkowników na najwyższym poziomie, a wraz ze współpracownikami na tablicy szkicuj interakcje na wysokim poziomie, które sugerują. To daje Ci pierwszy pomysł, co Duże moduły są; i iteracji lub dwóch z wysokiego poziomu CRC - karty Jak play należy ustabilizować listę głównych komponentów, co robią i jak wchodzą w interakcję.

Then, jeśli którykolwiek z obowiązków są duże lub złożone, udoskonalić te moduły w dół, aż masz rzeczy, które są małe i wystarczająco proste, aby być obiektami, odtwarzając interakcje wewnątrz modułu dla każdej z głównych operacji zidentyfikowanych przez interakcje wyższego poziomu.

Wiedząc, kiedy przestać jest kwestią osądu (który przychodzi tylko z doświadczeniem).

Polecam Ci używać BlueJ a także ActiveWriter do nauki, a także do rozwijania dobrego zrozumienia przedmiotów. Polecana książka jest również miłym zasobem.

From Wikipedia :

BlueJ jest zintegrowanym rozwojem Środowisko do programowania w Javie język, opracowany głównie dla celów edukacyjnych, ale także nadaje się do oprogramowania na małą skalę rozwój.

DODATKOWO używa UML i dla mnie był to dobry zasób do zrozumienia kilku rzeczy na temat modelowania obiektów.

Alt text http://www.ryanknu.com/ryan/bluej.png

ActiveWriter jest narzędziem do modelowania jednostek i relacji, generuje również kod i jest łatwy do wprowadzania zmian. Pozwoli to zaoszczędzić czas, a zwinny rozwój jest bardzo odpowiedni.

Alt text http://altinoren.com/activewriter/Images/Introduction_1.png

Myślę, że odpowiedź tutaj powinna być bardzo inna w zależności od rzeczywistych doświadczeń faceta pytającego.

Jeśli masz tylko jedno lub dwa lata doświadczenia zawodowego, musisz przejść do punktu, który jest: Jak dotrzeć do punktu, w którym naprawdę znasz swoje dane i dokładnie rozumiesz, co próbujesz zrobić?

Tak, jeśli pracujesz w realnym świecie ponad 5 lat, możesz wybrać jeden z wielu modeli procesów tworzenia oprogramowania lub techniki.

Ale nie zdobywa się doświadczenia czytając tylko książki. Powinieneś uczyć się pracując w dobrej grupie pod dobrym przywództwem.

Jeśli to nie jest możliwe, powinieneś zrobić to sam. Rozpocznij iterację od kodowania prawdopodobnie bardzo paskudnego kawałka kodu, uczenia się błędów, wyrzucania wszystkiego, kodowania lepszego i tak dalej.

Dowiesz się wiele o swojej bazie kodowej. Narzędzia są narzędziami, niczego Cię nie nauczą.

Po pierwsze - design powinien pochodzić z twojej duszy. Musisz to czuć po każdym włóknie. Zazwyczaj chodzę nim przez dwa lub trzy miesiące, zanim zacznę cokolwiek robić, po prostu chodząc ulicami (naprawdę). I myśleć. Chodzenie to dobra medytacja. Pozwala więc dobrze się skoncentrować.

Po drugie-używaj OOP i klas tylko tam, gdzie istnieje naturalna hierarchia obiektów. Nie "wkręcaj" tego sztucznie. Jeśli nie istnieje ścisła hierarchia (jak w większości firm aplikacje) - przejdź do proceduralnych / funkcjonalnych, lub przynajmniej używaj obiektów tylko jako kontenerów danych z izolowanymi accesorami.

I ostatnia-spróbuj przeczytać to: algorytm twórczego myślenia

Just quoting http://www.fysh.org / ~katie/computing/methodologies.txt

A u podstaw RUP jest mały obszar, gdzie trzeba użyć OO design talenty.... jeśli ich nie masz, to jak mieć metodologię dla bieg na 100m.

"Krok 1: napisz o bieganiu naprawdę szybko. Krok 2: Idź i narysuj plan toru wyścigowego. Krok 3: Idź i kup naprawdę obcisłe spodenki z Lycry. Krok 4: biegnij bardzo, bardzo szybko. Krok 5: pierwszy krzyż linii "

It ' s that step 4 to jest trudne. Ale jeśli kładziesz duży nacisk na 1,2,3 i 5 jest możliwe, że nikt nie zauważy i wtedy można prawdopodobnie zarabiać dużo pieniędzy sprzedając metodologię, aby być sportowcy, którzy myślą, że jest jakiś "sekret" bycia biegaczem na 100 M

Zadałeś pytanie, którego wielu autorów używa do napisania książki. Metodologii jest wiele i powinieneś wybrać taką, która wydaje ci się" najładniejsza".
Polecam książkę "Domain Driven Design" autorstwa Erica Evansa. Sprawdź też Stronę dddcommunity.org .

1. Studiuj i opanuj wzorce projektowe.
2. następnie dowiedz się więcej o Domain Driven Design
3. Potem naucz się zbierać wymagania

Brałem kurs OOD kilka semestrów z powrotem i wiele się z tego nauczyłem; jak pisanie UML i tłumaczenie wymagania dokumenty do obiektów i klasy. Nauczyliśmy się sekwencji diagramów też ale jakoś przegapiłem wykład czy coś, oni nie trzymaj się mnie.

1. Wiesz o kroku 3. Musisz to opanować. Mam na myśli, przez wiele praktyki, aby stało się to twoją drugą naturą. To dlatego, że metoda, której się uczysz, jest po prostu przeciwna temu, co kiedyś mieliśmy. Więc musisz to naprawdę opanować. W przeciwnym razie zawsze wrócisz do swojego oryginalnego sposobu robienia rzeczy. Jest to w jakiś sposób proces testowy, w którym wielu programistów Javy rezygnuje z niego po kilku próbach. Chyba, że w pełni go opanują, w przeciwnym razie jest to tylko ciężar do them

2. Napisz przypadki użycia, szczególnie dla kursu alternatywnego. Kurs alternatywny zajmuje ponad 50% naszego czasu rozwoju. Normalnie, gdy PM przypisać zadanie, na przykład, utworzyć system logowania, będzie myśleć, że to prosto do przodu, można wziąć 1 dzień, aby zakończyć to. Ale nigdy nie bierze pod uwagę, że trzeba wziąć pod uwagę, 1. co jeśli Klucz użytkownika w niewłaściwym hasłem, 2. co się stanie, jeśli użytkownik wprowadzi błędne hasło 3 razy, 3. co jeśli użytkownik nie wpisze nazwy użytkownika itd. Potrzebujesz aby je wymienić i pokazać premierowi, poproś go o przesunięcie terminu.

Obawiam się, że to nie jest Odpowiedź ludzie lubią słuchać . W każdym razie, pozwól mi wyrazić swoją opinię.

OOP powinien być postrzegany jako jeden z paradygmatów, a nie jako nadrzędny paradygmat. OOP jest dobry do rozwiązywania pewnych problemów, takich jak tworzenie biblioteki GUI. Wpisuje się to również w styl tworzenia oprogramowania, który zazwyczaj kierują duże firmy programistyczne - elitarny zespół projektantów lub architektów opracowuje projekt oprogramowania na diagramach UML lub innych podobne medium i mniej oświecony zespół programistów tłumaczą ten projekt na kod źródłowy. OOP oferują niewielkie korzyści, jeśli pracujesz sam lub z małym zespołem wysoce utalentowanych programistów. Następnie lepiej jest użyć języka, który obsługuje wiele paradygmatów i pomoże Ci szybko wymyślić prototyp. Python, Ruby, Lisp / Scheme itp. są dobrym wyborem. Prototyp jest twoim projektem. To się popraw. Użyj paradygmatu, który jest najlepszy, aby rozwiązać problem. Jeśli potrzebne, Optymalizuj hot spoty z rozszerzeniami napisanymi w języku C lub innym języku systemowym. Używając jednego z tych języków, otrzymujesz również rozszerzalność za darmo, nie tylko na poziomie programisty, ale także na poziomie użytkownika. Języki takie jak Lisp mogą dynamicznie generować i wykonywać kod, co oznacza, że użytkownicy mogą rozszerzyć aplikację, pisząc małe fragmenty kodu, w języku, w którym samo oprogramowanie jest kodowane! Lub jeśli zdecydujesz się napisać program w C lub c++, rozważ umieszczenie tłumacz dla małego języka, takiego jak Lua. Wyświetla funkcjonalności jako pluginy napisane w tym języku.

Myślę, że większość czasu OOP i OOD tworzą oprogramowanie, które są ofiarami ponad projektowania.

Podsumowując, mój preferowany sposób pisania oprogramowania to:

1. użyj dynamicznego języka.
2. napisz projekt (prototyp) w tym języku.
3. jeśli to konieczne, zoptymalizuj niektóre obszary za pomocą C / C++.
4. zapewniają rozszerzalność poprzez interpreter samego języka implementacyjnego.

Ostatnia funkcja umożliwia łatwe dostosowanie oprogramowania do konkretnego użytkownika (w tym mnie!) wymagania.

Jeśli posiadasz wiedzę domenową na temat projektu, nad którym będziesz pracował, jak np. Bankowość. Łatwo jest uporządkować obiekty i wiesz, jak te ulepszenia przychodzą co drugi dzień.

Jeśli nie masz tej wiedzy, pracuj z kimś, kto ma tę wiedzę i przekształć te pomysły w szczegóły techniczne.

Jeśli jesteś zdezorientowany, jak uporządkować swój projekt. Ślepo podążaj za książką "pragmatyczny programista". Byłem wcześniej w takiej samej sytuacji, spróbuj przeczytać rozdział z ta książka. zobaczysz różnicę, zmieni to sposób myślenia jako programista.

Używam Test-Driven Design (TDD). Napisanie testu po raz pierwszy rzeczywiście pomaga doprowadzić do projektu, który jest czysty i poprawny. Zobacz http://en.wikipedia.org/wiki/Test-driven_development .

Poznaj wzorce projektowe . To była moja osobista rewolucja w ciągu ostatnich dwóch lat w sprawie OOP. Kup książkę. Polecam ten:

Head First Design Patterns

Jest w Javie, ale można go rozszerzyć na dowolny język.

Szczerze mówiąc, dobrym krokiem byłoby cofnięcie się i spojrzenie na wykresy przepływu i diagramowanie sekwencji. Jest mnóstwo dobrych stron, które pokazują, jak to zrobić. Uważam, że jest to bezcenne, gdy patrzę, jak chcę rozbić program na klasy, ponieważ Wiem dokładnie, czego program potrzebuje wprowadzany, obliczany i wyprowadzany, a każdy krok można podzielić na jedną część programu.

Jak odpowiedziano w Jaki jest przepływ pracy, który kierujesz, aby zaprojektować oprogramowanie, które zamierzasz napisać?

Jedną z przydatnych technik jest odniesienie swojego unikalnego opisu problemu do czegoś, co można znaleźć w prawdziwym świecie. Na przykład, modelujesz złożony system opieki zdrowotnej, który zabierze świat przez burzę. Czy są jakieś przykłady, które można łatwo przywołać, aby to modelować?

W rzeczy samej. Obserwuj, jak działa apteka boczna, lub pokój lekarza.

Sprowadzenie problemu z domeną do czegoś zrozumiałego dla ciebie; czegoś, z czym możesz się odnieść.

Wtedy raz "gracze" w domenie zaczynają wydawać się oczywiste, a Ty zaczynasz modelować swój kod, wybierasz podejście modelowania "dostawca-konsument", tzn. Twój kod jest" dostawcą "modelu, a ty jesteś"konsumentem".

Odniesienie do dziedziny i zrozumienie jej na wysokim poziomie jest kluczowym elementem każdego projektu.

Podczas moich przygód z projektowaniem struktur klasowych zauważyłem, że bardzo pomocne jest zacząć od napisania jakiegoś pseudo-kodu. To znaczy: zaczynam od" pisania " ogólnych fragmentów kodu aplikacji na najwyższym poziomie, bawię się nim i odkrywam elementy, które się pojawiają – w rzeczywistości elementy, z których ja – jako programista – chciałbym korzystać. Jest to bardzo dobry punkt wyjścia do projektowania ogólnej struktury modułów i ich interakcji. Po kilku iteracjach cały struktura zaczyna wyglądać bardziej jak pełny system klas. Jest to bardzo elastyczny sposób projektowania części kodu. Można to nazwać projektem zorientowanym na programistów.