The fundamental program structure in an object-oriented program is the object.
To understand the notion of objects and classes, we start with an analogy...
When a car manufacturer decides to build a new car, considerable effort is expended in a variety of activities before the first car is rolled out of the assembly lines. These include:
• Identification of the user community for the car and assessment of the user’s needs.
For this, the manufacturer may form a team.
• After assessing the requirements, the team may be expanded to include automobile
engineers and other specialists who come up with a preliminary design.
• A variety of methods may be used to assess and refine the initial design (the
team may have experience in building a similar vehicle): prototypes may be built,
simulations and mathematical analysis may be performed.
Perhaps after months of such activity, the design process is completed. Another step that needs to be performed is the building of the plant where the car will be produced.
The assembly line has to be set up and people hired.
After such steps, the company is ready to produce cars. The design is now reused
many times in manufacture. Of course, the design may have to be fine-tuned during
the process based on the company’s observations and user feedback.
The development of software systems often follows a similar pattern. User needs
have to be assessed, a design has to be made, and then the product has to be built.
From the standpoint of object-oriented systems, a different aspect of the car manufacturing process is important. The design of a certain type of car will call for specific types of engine, transmission, brake system, and so on, and each of these
parts in itself has its own design (blue print), production plants, etc. In other words,
the company follows the same philosophy in the manufacture of the individual parts as it does in the production of the car. Of course, some parts may be bought from manufacturers, but they in turn follow the same approach. Since the design activity is costly, a manufacturer reuses the design to manufacture the parts or the cars.
The above approach can be compared with the design of object-oriented systems
which are composed of many objects that interact with each other. Often, these objects represent real-life players and their interactions represent real-life interactions. Just as design of a car is a collection of the individual designs of its parts and a design of the interaction of these parts, the design of an object-oriented system consists of designs of its constituent parts and their interactions.
For instance, a banking system could have a set of objects that represent customers, another set of objects that stand for accounts, and a third set of objects that correspond to loans. When a customer actually makes a deposit into her account in real life, the system acts on the corresponding account object to mimic the deposit in software.
When a customer takes out a loan, a new loan object is created and connected to the customer object; when a payment is made on the loan, the system acts on the corresponding loan object.
Obviously, these objects have to be somehow created. When a new customer enters the system, we should be able to create a new customer object in software.
This software entity, the customer object, should have all of the relevant features of the real-life customer. For example, it should be possible to associate the name and
address of the customer with this object; however, customer’s attributes that are not relevant to the bank will not be represented in software. As an example, it is difficult to imagine a bank being interested in whether a customer is right-handed; therefore, the software system will not have this attribute.
Top comments (0)