Jak podchodzisz do projektowania klas w OOP?

Kiedy próbuję zaprojektować rozwiązanie OO, zwykle używam modelowania CRC, w którym wymieniam nazwy klas (rzeczowniki), co robią (czasowniki) i jak współpracują z innymi klasami.

Ten blog ma poniżej do powiedzenia na temat tego czasownika

   ...This approach, which I will call “noun and verb,” is so limited 
   I’ll dare to call it brain damaged....

Moje pytanie brzmi: czy istnieje lepsza technika modelowania do zastosowania podejścia OO?

Uczciwie dodał „Do zabawy” do tego roszczenia.

Do dziś zaczynam od modelowania systemów przy użyciu metody „rzeczownik i czasownik”, ale przez lata odkryłem, że TDD uczy nas, że takie podejście kieruje uwagę na niewłaściwe rzeczy. W tym sensie blogger ma rację. Nie jestem jednak pewien, czy jest to wina zawinionego podejścia, a nie sposób, w jaki działają nasze umysły.

Jeśli chcesz spróbować małego wyzwania tutaj, przestań czytać i spróbuj modelować grę Monopoly, używając języka angielskiego, a następnie wróć tutaj.

Podejrzewam, że pokusa polegać będzie na natychmiastowym spojrzeniu na przedmioty, z którymi często wchodzimy w interakcję - planszę, przestrzenie, karty, kostki, pionki - ale nie na tym polega logika. Większość tych obiektów jest całkowicie głupia. Dane, jeśli chcesz.

Ale jak tylko zaczniesz pisać testy, zdajesz sobie sprawę, który obiekt jest zdecydowanie najważniejszy w każdej grze: zasady.

Pamiętasz ten kawałek papieru, który przeczytałeś kiedyś, gdy gra była dostępna, i nie wchodziłeś w interakcje, dopóki nie dojdzie do sporu? Wersja komputerowa nie działa w ten sposób. Każda rzecz, którą gracz próbuje zrobić, komputer sprawdzi zasady i sprawdzi, czy wolno to zrobić, czy nie.

Kiedy myślisz o tym, robisz to samo, ale ponieważ przeczytanie papierowych zasad wymaga czasu, a twój mózg ma rozsądny system buforowania, zapoznajesz się z zasadami w twojej głowie. Komputer prawdopodobnie uzna, że ​​tak łatwo będzie ponownie przeczytać reguły - chyba że są one przechowywane w bazie danych, w którym to przypadku może je również buforować.

I właśnie dlatego TDD jest tak popularny ze względu na stylistykę jazdy. Ponieważ ma tendencję do szybkiego kierowania procesem myślowym we właściwe miejsca:

Kiedy myślę, że napiszę kilka testów do mojej gry Monopoly. Mogę spojrzeć na mój zestaw i spróbować znaleźć przedmioty. Mamy więc te kawałki. Napiszę dla nich kilka testów.

Może będę miał podstawową MonopolyPiece i każdy rodzaj elementu będzie z nich czerpał. Zacznę od DogPiece. Pierwszy test ... ahh. Właściwie nie ma tutaj logiki. Tak, każdy kawałek zostanie narysowany inaczej, więc może potrzebuję DogDrawer, ale kiedy rozwijam grę, chcę po prostu napisać „D” na ekranie. Pod koniec dopracuję interfejs użytkownika.

Znajdźmy rzeczywistą logikę do przetestowania. Istnieje wiele takich domów i hoteli, ale nie wymagają one testów. Pieniądze, nie. Karty własności, nr I tak dalej. Nawet tablica jest niczym innym jak maszyną stanu, nie zawiera żadnej logiki.

Szybko przekonasz się, że masz trzy rzeczy w ręku. Karty szans i wspólna skrzynia, para kości i zestaw zasad. Będą to ważne części do zaprojektowania i przetestowania.

Widziałeś to, kiedy pisałeś rzeczowniki i czasowniki?

W rzeczywistości jest świetny przykład wzorców i praktyk Agile Roberta Martina, w których starają się opracować aplikację karty wyników gry w kręgle za pomocą TDD i znaleźć wszelkiego rodzaju rzeczy, które według nich były oczywistymi zajęciami, po prostu nie warto się nimi przejmować.

Nigdy nie znalazłem dla siebie takich metod. W rzeczywistości odkryłem, że używanie ich tylko myli mnie jeszcze gorzej. Sprawdź ekspres do kawy Roberta C. Martina. Nie wydaje mi się, żeby on również stosował takie podejście.

Jedną z rzeczy, która od razu mnie niepokoi, jest rozwiązanie, do którego dana osoba wchodzi w artykule CRC, do którego linkujesz. Współpraca klienta z zamówieniem nie jest czymś, co uważam za wartościowe, a nie tak napisane. W tym modelu nie ma nic szczególnie interesującego w przypadku Klienta, który zasługuje na status klasy. Jedyną interesującą rzeczą w byciu „klientem” jest to, że z tą osobą jest powiązane jedno lub więcej zamówień .

Model uczelni również. Jest wiele rzeczy, które mogą i prawdopodobnie powinny być dzielone między Studentem i Profesorem. Co ponadto dzieje się, gdy profesor bierze udział w zajęciach, co bardzo często jest bezpłatne na kampusach uniwersyteckich?

Przypuszczam, że może to być cenna praktyka, jeden element w zestawie narzędzi do projektowania. Nie sądzę, że powinien to być jedyny sposób, w jaki podchodzisz do projektowania. Szczerze mówiąc, bardziej przydatne wydaje mi się podejście do analizy podobieństwa / zmian. Wydaje mi się, że bardzo dokładnie modeluję to, co robimy, klasyfikując abstrakcje w życiu codziennym.

Edycja: Wystarczy przeczytać połowę tego drugiego bloga i muszę przyznać, że całkiem się z tym zgadzam. Będę musiał przeczytać resztę i zobaczyć, co oferuje w zakresie nauki.

Moim zdaniem klasy powinny być dodawane (i usuwane) podczas pisania kodu w celu oddzielenia problemów i zmniejszenia zależności. Biegła we wzorach projektowych jest prawdopodobnie dobrym wyborem, aby zobaczyć możliwości refaktoryzacji i uproszczenia.

Klasy ogólnie, z mojego doświadczenia, nie mieszczą się w kategoriach rzeczowników / czasowników, ale raczej kończą się mieszanką klas rzeczowników / czasowników wraz z różnymi klasami wzorców (fabryki, singletony, wzorce strategiczne itp.) I innymi klasami menedżerskimi który dotyczy aspektu twojej aplikacji.

Kluczową sprawą jest to, że Twoim celem powinno być spojrzenie na klasę i wydedukowanie tego, co ona robi, i zmodyfikowanie tego poprzez zmianę tej klasy. Im więcej kodu dla aspektu twojej aplikacji jest rozłożone na klasy, tym trudniej jest go śledzić, zarządzać i rozszerzać.