Moving from Procedural to Object-Oriented Development
Last month's article introduced some basic object-oriented concepts as well as some of the differences between procedural and object-oriented technologies. Now, let's delve a bit deeper into these topics.
Procedural programming separates the data of the program from the operations that manipulate the data. For example, if you want to send information across a network, only the relevant data is sent (see Figure 1), with the expectation that the program at the other end of the network pipe knows what to do with it. In other words, some sort of handshaking agreement must be in place between the client and server to transmit the data. In this model, no code is actually sent over the wire.Figure 1 - Data transmitted over a wire.
The fundamental advantage of OO programming is that the data and the operations that manipulate the data (the code) are both encapsulated in the object. For example, when an object is transported across a network, the entire object, including the data and behavior, goes with it. In Figure 2, the Employee object is sent over the network.
A good example of this concept is a Web object, such as a Java applet. The browser has no idea of what the Web object will do. When the object is loaded, the browser executes the code within the object and uses the data contained within the object.
Figure 2 - Objects transmitted over a wire.
What Exactly Is an Object?
Objects are the building blocks of an OO program. A program that uses OO technology is basically a collection of objects. To illustrate, let's consider that a corporate system contains objects that represent employees of that company. Each of these objects is made up of the data and behavior described in the following sections.
The data stored within an object represents the state of the object. In OO programming terminology, this data is called attributes. In our example, as shown in Figure 3, employee attributes could be Social Security number, date of birth, gender, phone number, and so on. The attributes contain the information that differentiates between the various objects, in this case the employees. Attributes are covered in more detail later in this series when classes are covered.
Figure 3 - Employee attributes.
The behavior of an object is what the object can do. In procedural languages, the behavior is defined by procedures, functions, and subroutines. In OO programming terminology, these behaviors are contained in methods, and you invoke a method by sending a message to it. In our employee example, consider that one of the behaviors required of an employee object is to set and return the values of the various attributes. Thus, each attribute would have corresponding methods, such as setGender() and getGender(). In this case, when another object needs this information, it can send a message to an employee object and ask it what its gender is.
Getters and Setters
The concept of getters and setters supports the concept of data hiding. Because other objects should not directly manipulate data within another object, the getters and setters provide controlled access to an object's data. Getters and setters are sometimes called accessor methods or mutator methods.
Note that we are only showing the interface of the methods, and not the implementation. The following information is all the user needs to know to effectively use the methods:
- The name of the method
- The parameters passed to the method
- The return type of the method
To further illustrate behaviors, consider Figure 4.
In Figure 4, the Payroll object contains a method called CalculatePay() that calculates the pay for a specific employee. Among other information, the Payroll object must obtain the Social Security number of this employee. To get this information, the payroll object must send a message to the Employee object (in this case, the getSocialSecurityNumber() method). Basically, this means that the Payroll object calls the getSocialSecurityNumber() method of the Employee object. The employee object recognizes the message and returns the requested information.
Figure 4 - Employee behaviors.
To illustrate further, Figure 5 is a class diagram representing the Employee/Payroll system we have been talking about.
Figure 5 - Employee and payroll class diagrams.
UML Class Diagrams
Because this is the first class diagram we have seen, it is very basic and lacks some of the constructs (such as constructors) that a proper class should contain. Fear not; we will discuss class diagrams and constructors in more detail later in the series.
Each class diagram is broken up into two separate sections (besides the name itself). The first section contains the data (attributes), and the second section contains the behaviors (methods). In Figure 5, the Employee class diagram's attribute section contains SocialSecurityNumber, Gender, and DateofBirth, whereas the method section contains the methods that operate on these attributes. You can use programming tools such as Rational Rose or Borland Together to create and maintain class diagrams that correspond to real code.
Rational Rose and Borland Together are visual modeling tools that provide a mechanism to create and manipulate class diagrams by using the Unified Modeling Language (UML).