Whenever I was required to build a project, I always managed to build it, not beforehand devising a plan or design, but after first writing a class that was needed, fleshing out the entire project, building from the bottom-up. Now I know this is not the proper way to create software, but it is not easy for me to wrap my head around what is called Objected Oriented Analysis and Design. I can more easily understand top-down procedural design, for it consists in merely breaking down tasks into sub-tasks, things which have their counterpart in code, functions. But Object Oriented Analysis and Design I cannot easily understand, for I do not understand how one can know what classes they will need and how they will interact, unless they know how they will code them.
For once we introduce the concept of classes and objects into the design process, we can no longer design top-down, because we are no longer breaking down our problems into those things which can be implemented as procedures. Instead, according to what I have read on the subject, we must determine what classes are needed, and create various artifacts in Unified Modelling Language, which we can then use when we implement the software. But this kind of design process I do not understand. For how does one know which classes they will need, and how they will interact, unless they have already conceived of the whole system?
This then is my problem. I do not understand how to design an Object-Oriented System, although I do understand the concepts of Object Oriented Programming, and can use those concepts in any Object Oriented Programming language that I know. Therefore I need someone to explain to me what simple process I can use to design Objected Oriented Systems in a way that makes sense to me.
Best Answer
Top down waterfall style OOAD does not ensure that the code you write is object oriented at all. I have seen mountains of strictly OOAD produced code that proves it. If OO is confusing you, don't look here for help. You wont find it. OO does NOT require you to design top down.
If diving into a class is how you like to code, so be it. Let me tell you a hint. Procrastinate.
It's amazing how easy it is to design classes by writing code that uses them even when they don't exist yet. Forget procedure. Forget structure. Just get yourself a nice consistent level of abstraction going and stick with it. Don't give into temptation and mix extra details into it. Anything that takes you out of the current abstraction can go be done in some method that might be on some other object that somehow knows whatever it needs to know. Don't build anything you can just ask to be handed to you.
Learn to write like that and you'll find you're doing OO without even trying very hard. This forces you to look at your objects from the point of view of how they are used (their interface) and which objects know about which other objects. Guess what a UML diagrams main two points are?
If you can get into that mode of thinking then what's left is architecture. We're all still figuring that out. From MVC to clean architecture to domain driven design. Study them and play. Use what works. If you find something 100% reliable come back and let me know. Been doing this for decades and I'm still looking.