Software Design and the Object-Oriented Approach

There are many different approachs to the design of software systems. Over the years, we have developed and taught many different design methodologies. In the past, we began programming courses discussing flow charts and/or top-down diagrams. And sometimes we even discussed the merits of bottom-up approaches. But, these approaches proved too limited for complex problems and a new methodology came to light, object-oriented programming (OOP).

At the heart of the object-oriented approach are objects. Don't expect a complex mathematical description or a long technical definition. You won't find one, at least here. Instead let me just suggest that objects are all of the individual identifiable components of a system. If you want to point at it, name it, use it, or talk about it, it is an object.

One way of discovering the objects in a system is to describe the system to someone else. Then consider all of the nouns that you used in your description. These are probably objects.

A very important piece of object-oriented design is, as you might imagine, describing the objects within the system. Again, a conversational model might be useful here. Often times when we describe things to each other, we will talk about the objects first in terms of their behavior. For example, if a little child asks you, "What is a car?" You would first tell the child that it can move forward and backward and turn. And then you would tell the child that it can carry people. Eventually you would tell the child that cars come in all different colors, and that some have two doors and others four doors, &c.

This is the same process that we'll use to describe the objects in software systems. After we identify each object, we'll ask ourselves, "What does this object do?" We call the things that an object can do its behaviors. We also ask ourselves, "What do we need to tell it to get it to do these things? What does it need to know?" For example, if we want a car to move forward, we need to tell it, "how fast". If we want it to turn left, we have to tell it, "how much". These are the parameters of its behaviors.

After considering , "What can the object do?" We'll ask ourselves, "What are the other properties of the object?" What color is it? How big is it? How many doors does it have? These aspects of an object we call its attributes.

Many of these attributes are visible attributes, we can observe them from outside of the object. But, some of the attributes we can only discover by inference. We'll call these the hidden attributes.

For example, if we consider a typical calculator, the only number we can see on the display is the most recent input. But, by observing how a calculator adds and subtracts, we can infer that it maintains an accumulator containing the most recent result. We can't see the accumulator, but we know that it must exist -- without it, we cannot explain the behavior of the calculator.

Classes: Different Types of Objects

If I would ask you to describe the contents of a room with only one person inside, you would probably describe that one person, possibly by name. But, if I would ask you to describe a room with 100 strangers inside, you would probably approach the problem slightly differently.

You would describe a generic person first. You would tell me what all people have in common, and how they differ. Then, you would tell me about each object in the room by first identifying it as a person, and then telling me about how it is special -- by describing its collection of attributes.

In object-oriented languages, we can do exactly the same thing. We can describe types of objects, a.k.a., classes of objects. We do this by writing a class specification that describes the behaviors and attributes of a class of objects. Then, when we create a new object, we do it by building them according to thier class specification and "filling in the blanks" for each attribute. So, in object oriented languages, new objects are "instances of a class" meaning that they are built according to some class specification.

That's a whole bunch of computer lingo, so lets apply it to the car example. We can define a class for the object "car." We observe that cars can have differing numbers of doors, differing sizes of engines, and differing colors, but are all capable of moving forward, backward, and turning left and right. Thus the class specification would include the car's attributes (number of doors, size of engines, and color) and its behaviors (moving forward and backward, and turing). Then, we can create an instance of the car class, filling in the specifications. If the instance is a ferrari, the new object should be be red and have two doors and a V8 engine.

Food for thought: Sometimes in using the car we might be concerned with how it looks -- and on other occasions we just might want to go for a spin without worrying about its color.

The Object-Oriented Approach to Controling a Room's Temerature

To help you guys with possible questions, a small example follows. Let's model something in the real world, controling the temperature in one of the 5419 clusters:

• What would affect the room's temperature?
• Size of the room
• Openings (such as doors)
• Heat sources
• People - what level of physical activity?
• Sitting
• Running/ doing jumping jacks
• Computers - What is the screen's brightness?
• Sleeping/ dark
• Active/ bright

You would then model the room by defining it's size and openings and then populating it with heat sources (the objects). People and Computers are two different objects and thus two different class types with different specifications. If you weren't using an OO (object oriented) approach you might model the room and each person/computer in it individually (as opposed to grouping them as types of objects). However, that approach has several disadvantages:

1. It would take alot more time (since you have to rewrite similar code for each Person or Computer).
2. It would be harder to read/ interpret.
3. Additions or changes to People's attributes would have to be individually recoded. (For example: if their clothing changed from summer weight to winter coats it's eaiser to only change the specification of the class "People" and not the coding describing each individual)

Another advantage to OOP: The classes created to solve one problem can be used to populate another room/ solve another problem (like how to heat a conferance room).

When you are done modeling the room note that it has been populated with People and Computers in other words its composition is of People and Computers.

Object-Oriented Programming and Message Passing

How do we ask objects (or students acting as objects) to exhibit these behaviors? -- we simply ask, e.g., "Please, stand up" and the student stood up. In other words we send a message to the object and ask it to do something. In return the object does what we ask and we observe when it is done.

Sometimes the requests were simple and required no other information, such as, "Stand", whereas others were more complicated and required more information, such as "Jump 2 feet." We call such additional pieces of information paramters or arguments because they describe the specifics of a particular action.

In the language of object-oriented programming, we send a message or request and recieve a reply. The message communicates what we want done and the reply indicates that the action has been taken, and if appropriate, includes a result.

Types of Behaviors

Sometimes we ask objects to tell us things about themselves, but to change nothing. For example, I can ask you for your name -- that gives me a piece of information without changing anything about you. This type of method is often called an accessor.

Other methods actually cause an object to change something about itself. For example, if I ask you to "Stand up", you rise, changing your position. This type of method is known often called a "mutator".

Sending a message to one object can cause it, in turn, to communicate with other objects by sending them messages. These more complicated behaviors can have more complex or subtle effects on many different parts of the system.

As one example, I asked someone in the class to tell me the average age of the three people nearest to her/him. This required asking three people for their age, averaging, and returing the value to me.

As another example, I launched a virus. I asked someone in the class to introduce himself to two other people, and in the process, ask each to do exaclty the same thing. Before long, each person was asking other people to introduce themselves to two other people, and being asked to do the same! Obviously this request had a huge effect on our sytem, the classroom.

Capabilities and Protocols

For two objects to interact, there must be agreement about two things: The capabilities of each object and the proper way to make a request and receive a reply from an object.

In class, I ordered one person to fly and hover in the corner of the room. Another person was ordered to burrow down to the center of the Earth. Each request was met with a confused look, some laughter, and a complete lack of compliance by the student who was asked to act. The basic problem is that a Students can't fly or borrow. These, quite simply, are not behaviors of humans. We are such limited creatures.

As another demonstration, I asked students to volunteer themselves as native speakers of foreign languages. From the volunteers, I selected a student who spoke an obscure language. That student was asked to make a request, in the foreign language, of another student. The request was to be for a G-rated, non-embarassing, general-audience-accessible behavior that the student could, in fact, readily exhibit.

In each case, even after several attempts, the target student didn't perform the requested action -- she or he didn't understand the request. The requested actions were things such as stand up, and introduce yourself to a nearby person. Clearly the target student would have satisfied the request -- if only it was understood.

These demonstrations were designed to highlight two important aspects of the interaction among objects:

1. Objects can't exhibit behaviors other than those that are characteristic of their type of object. People can't fly.
   
   
2. There must be agreement between the requesting objected and the target object about the format of the messages. What is the behavior called? What other information needs to be sent? What will be sent back, if anything, once the request is complete?

In short, we need to define, in advance, the protocol by which objects will communicate.