Steps to follow when trying to OO design an problem statement

Question

What are the steps that you follow when approaching a problem statement, which needs to be converted in to a OO design. I do know the approach might be subjective depending on the problem and varying for each but I am sure there must be some basic generic steps that each good designer will follow while breaking down a problem statement in to objects and classes and further to a much concrete design. Just trying to put up lets say a procedure to follow for new bee designer wannabe's like me.

Answer 1

One of the important steps during a OO design would be the "Single Responsibility Principle". Which is pretty much major basis towards a good design. A http component in your design would do http communication to retrieve jobs but would definitely avoid processing these jobs. The Jobs processor must be independent. Both these (http and job processor) have their single responsibility assigned to them. This is more a general view and inside your components you would create further classes that follow this principle as well.

Answer 2

I recommend the free online book http://my.safaribooksonline.com/0131489062/ch01 . It introduces some architectural concepts as well as UML. UML is a diagram tool to map out a design, and is really useful especially for planning large designs before sitting down and coding them.

Answer 3

I wouldn't have been happy with this answer when I was starting out but... it takes a lot of study and practice before it becomes second nature. The best advice I can give is to study designs from people you respect, read some good books (GOF design patterns is a good place to start), and ask experienced people to pick apart your designs.

Learn about things like the single responsibility priciple but you will also need to get a feel for "what is the right size" vs. over-engineering something. That will ultimately depend on the requirements.

Answer 4

while reading the problem, keep a list of the nouns as they might become classes and verbs might become methods. afterwards, go through them again and validate.

you must read books on design patterns (Head First Design Patterns is very good.) as they will give you a really good insight into how to design better.

don't forget to read on Architectural patterns too.

Answer 5

I would suggest following steps. 1. Write use case. It will help you to understand problem, it should contain basic execution flow (correct path) and alternate paths. 2. Do linguistic analysis and find out class and methods. (This is optional if you know any other good method then use it.) 3. Use SOLID principal for designing your classes. 4. Keep encapsulation, inheritance, polymorphism in mind. If you can't remember them write it on paper or stick it on your desk. 5. One more thing you should keep in mind "What varies encapsulate it". 6. Use design patterns when they are required. Don't enforce design pattern to your code. Try to map your design problem to any design pattern.

I would also suggest "Head First OOAD" book. It is very good book for leaning OOAD.