PDF of this tutorialFor each of these objects the analyst asks what the object should know or what its attributes are. We would expect customers to know their names and dwellings to know their addresses. Next the analyst determines what each object should know how to do or its behavior. The programmer will trigger this behavior by sending a message to the object. A piece of equipment might accept messages to turn a feature on or off, for example. If a designer were modeling a dog using object-oriented programming, then, it might have attributes of a name, hair color, and weight. Its behavior could be how it responds to the messages "speak," "sit," and "roll over."
The analyst must also identify intangible things in the system that might qualify as an object, such as a person's membership in a club. A membership would have attributes such as the beginning date. It might also have behavior that would cause the membership to cease.
The goal of this kind of analysis is to provide a better set of abstractions for building the software solution. The objects form a simplified model of the business problem domain. With an OO design developers can ask, "What object should know that?" or "What object should do that?" This strong sense of belonging created by careful design of the objects leads to systems that are easier to understand, maintain, and extend.
A further goal of OO programming is to encapsulate the details. For each object, the interface must be carefully designed to hide the details of implementation from the user of the object. When the equipment object gets the message to turn a feature on, the sender of the message does not need to know how that feature is enabled. Encapsulation like this promotes understanding of the system by minimizing the details that a user must know at any one time. If a new way to enable a feature on the equipment emerges, only the equipment object must change. Thus, encapsulation simplifies maintenance of the application.
Two other common attributes of OO programming are inheritance and polymorphism. OO programming environments provide an object with the ability to inherit from other objects. For instance, in a business system we might define a person as having attributes such as name, address, and home phone number. We could then create a customer, field technician, or sales representative by inheriting characteristics from the person object. All of these would pick up the name, address, and phone number attributes. Other attributes could then be added to the inheriting objects, such as a sales route for the salesman. Later, if we decided to add a birth date to the person object, all the other objects inheriting from the person will also automatically add the birth date attribute.
Polymorphism means that objects can respond differently to the same message. To illustrate polymorphism (as shown in Figure 10), let us say that we were modeling a dog, a cat, and a duck. We might send each of them the message to "speak." Each one would carry out the command, but in its own way (i.e., "woof," "meow," and "quack"). So, too, in the business system, we can send a message to all of the objects asking them to store their attributes. Each of them will behave differently in that they have different attributes to store. Yet they all receive and act upon the same message. This is a powerful concept that lets developers build systems that have consistent interfaces yet behave appropriately.
Figure 10. An Illustration of Polymorphism
Objects, or collections of objects can be used as components and plugged together to build complex systems. To accomplish this, an object middleware, or an infrastructure for communication, must be in place. Three popular infrastructures are
- CORBA—common object request broker architecture
- COM—common object model
- EJB—enterprise JavaBeans
These technologies provide a way to distribute objects across processes and computers and to let objects use other objects without knowing the object's location. CORBA and COM use an interface definition language (IDL) to publish objects and their capabilities. The IDL provides an insulating barrier and allows some flexibility so that developers can write objects in different programming languages and run them on different types of computers.
The selection of object middleware is a key architectural decision and is not easily changed. Because components must use other components through the middleware, the limitations and features of a middleware product work their way into code.
The use of object middleware such as CORBA or COM enables other user interfaces or systems to use the objects that have been written for one system. The combination of this middleware and the OO approach provide a better application program interface (API) than a collection of functions for two key reasons. First, the stronger abstractions provided with the OO technology make the interfaces easier to understand, and, second, the middleware gives the interfaces some independence from the programming language and platforms using the objects. Developers can write a piece of business logic once and use it across the intranet browser interface as well as with other user interfaces, such as the Internet and cellular digital packet data (CDPD) mobile phones.
