Ilekroć musiałem zbudować projekt, zawsze udało mi się go zbudować, nie wcześniej opracowując plan lub projekt, ale po napisaniu potrzebnej klasy, opracowując cały projekt, budując od podstaw. Teraz wiem, że nie jest to właściwy sposób tworzenia oprogramowania, ale nie jest mi łatwo owinąć głowę tym, co nazywa się analizą i projektowaniem obiektowym. Mogę łatwiej zrozumieć odgórny projekt proceduralny, ponieważ polega on jedynie na rozbiciu zadań na zadania cząstkowe, które mają swój odpowiednik w kodzie, funkcje. Ale analiza i projektowanie obiektowe nie mogę łatwo zrozumieć, ponieważ nie rozumiem, skąd można wiedzieć, jakich klas będą potrzebować i jak będą oddziaływać, chyba że będą wiedzieć, jak je kodują.
Gdy raz wprowadzimy pojęcie klas i obiektów do procesu projektowania, nie możemy już projektować odgórnie, ponieważ nie dzielimy już naszych problemów na te rzeczy, które można zaimplementować jako procedury. Zamiast tego, zgodnie z tym, co przeczytałem na ten temat, musimy określić, jakie klasy są potrzebne, i stworzyć różne artefakty w Unified Modeling Language, z których będziemy mogli korzystać podczas wdrażania oprogramowania. Ale tego rodzaju proces projektowania nie rozumiem. Bo skąd wiadomo, jakich klas będą potrzebować i jak będą wchodzić w interakcje, chyba że już wymyślili cały system?
To jest mój problem. Nie rozumiem, jak zaprojektować system obiektowy, chociaż rozumiem pojęcia programowania obiektowego i mogę korzystać z tych pojęć w dowolnym znanym mi języku programowania obiektowego. Dlatego potrzebuję kogoś, kto wyjaśni mi, jaki prosty proces mogę wykorzystać do zaprojektowania systemów zorientowanych obiektowo w sposób, który ma dla mnie sens.