Some people may be objecting at this point that OOP's detailed design approach is the only way to achieve a solid object model.
Sometimes, you write a program to use once and get an answer. In that case, full object-oriented analysis and design is not necessary and a prototype will fulfill the purpose.
But even prototypes have a habit of growing into legacy programs that go way beyond their original intent. It may take longer in the present to define the problem and its solution clearly, but in the long run, this approach saves substantial programmer time.
Object oriented design is part of OO methodology and it forces programmers to think in terms of objects, rather than procedures, when they plan their code.
An object contains encapsulated data and procedures grouped together to represent an entity. The object interface, how the object can be interacted, is also defined. An object oriented program is described by the interaction of these objects.
Object Oriented Design is the discipline of defining the objects and their interactions to solve a business problem that was identified and documented during object oriented analysis.
Have you ever had an experience like this? Why is it that you, an intelligent, educated person cannot read a large, prominently displayed sign, and follow a one-word instruction?
Why does everyone pull instead of push when presented with a door like the one shown in Figure 1.1?
The answer is really very simple: because the door handle itself is a sign, a sign that says more fundamentally and forcefully than the written sign above it. The design of the handle is an indication to PULL!
The problem is not with your ability to read, but with the designers of the building who combined an inward-opening front door with a door-pull instead of a push-plate.
Someone made a fundamental design error, and all the user-friendly instructions in the world will not fix it.
What is design?
What are the design fields, and how are creating architecture, graphic design, industrial design, and software design similar? As you ask these questions, you will discover many different viewpoints:
those who see design as science,
those who claim design for engineering,
those who feel design is an art, and
those who insist that design is a profession like law or medicine.
This module and the next explores those ideas as well as the common concepts of modeling, abstraction, and structuring, and how all of these ideas relate to developing software.