Object-Oriented Analysis and Design
By Bruce Eckel
To some, the object-oriented paradigm is a new and different way of thinking about programming, and many have trouble approaching a project. Now that everything is supposed to be an object, how do you create a design that takes advantage of all the benefits object-oriented programming (OOP) has to offer? This month, I shall endeavor to give you my perspective on analysis and design.
Staying on Course
It's easy to get lost during the development process. Most design methodologies are intended to solve the very largest of problems, but most projects don't fit into that category, so you can usually adopt a relatively small subset of the author's recommendation. The important thing is to have a plan. No matter how limited a process you follow, it's better than simply beginning to code.
That said, it may be difficult to know what to cull from a methodology that contains tremendous detail and suggests many steps and documents. Keep in mind what you're trying to discover:
- What are the objects, or, how do you partition your project into its component parts?
- What are the objects' interfaces, or, what messages do you need to be able to send to each object?
You can write a program with nothing more than the objects and their interfaces. You might need more descriptions and documents, but you can't get away with any less.
The design process can be undertaken in four phases, but first you need to decide what steps your process will include.
