|< Day Day Up >|
Procedural Versus OO Programming
Before we delve deeper into the advantages of OO development, let's consider a more fundamental question: What exactly is an object? This is both a complex and a simple question. It is complex because shifting gears to learn a totally new way of thinking is not an easy task. It is simple in the sense that most people already think in terms of objects.
For example, when you look at a person, you see the person as an object. And an object is defined by two terms: attributes and behaviors. A person has attributes, such as eye
Figure 1.1. Black boxes.
Difference Between OO and Procedural
This is the key difference between OO and procedural programming. In OO design, the attributes and behavior are contained within a single object, whereas in procedural, or structured design, the attributes and behavior are normally separated.
Procedural programming has been the mainstay since the Bronze Age of computers ”so why change? First, as
Figure 1.2. Using global data.
We can state that, when properly designed, there is no such thing as global data in an OO model. This fact provides a high amount of data integrity in OO systems.
Objects are much more than primitive data types, such as integers and strings. Although objects do contain entities such as integers and strings, which represent the attributes, they also contain methods, which represent the behaviors. In an object, you use the
In OO terminology, data is referred to as attributes, and functions are referred to as methods. Restricting access to certain attributes and/or methods is called data hiding .
By combining the data and methods in the same entity, which in OO parlance is called encapsulation , we can control access to the data in the Math object. By defining these integers as off-limits, another logically unconnected function cannot manipulate the integers myInt1 and myInt2 ”only the Math object can do that.
Sound Class Design Guidelines
Keep in mind that it is possible to create poorly designed classes that do not restrict access to class attributes. The bottom line is that you can design bad code just as
What happens when another object ”for example, myObject ”wants to gain access to the sum of myInt1 and myInt2 ? It asks the Math object: myObject sends a message to the Math object. Figure 1.3 shows how the two objects communicate with each other via their methods. The message is really a call to the Math object's Sum method. The Sum method then returns the value to myObject . The beauty of this is that myObject does not need to know how the sum is calculated (although I'm sure it can guess). In this example, you can change how the Math object calculates the sum without making a change to myObject (as long as the means to retrieve the sum do not change). All you want is the sum ”you don't care how it is calculated.
Figure 1.3. Object-to-object communication.
Calculating the sum is not the responsibility of
object's responsibility. As long as
has access to the
object, it can send the appropriate message and then obtain the result. In general, objects should not manipulate the internal data of other objects (that is,
should not directly change the value of
). And, for reasons we will explore later, it is normally better to build small objects with specific
|< Day Day Up >|