After writing Requirement Specification Document and planning your iterations, it is time for Object-Oriented Analysis and Design:
- What are your classes?
- How many should you have?
- What behavior will they implement?
- How much do they know about other classes?
- How much of themselves should they expose?
Deciding what classes to use (to implement a solution to a problem) can be a difficult task.
At this stage, your job is to design your classes so that they
- model your application
- are easy to change
Many of the decisions you make today will need to be changed later. When that day comes, your ability to successfully make those changes will be determined by your application's design.
What does "easy to change" mean?
Easy to change means that:
- small changes in requirements require correspondingly small changes in code.
- Changes would have obvious consequences (no unexpected side-effect).
The next few readings will help you to identify your "classes" and design them so that they are "easy to change".