The Object-Oriented Paradigm
The object-oriented paradigm is centered on the concept of the object. Everything is focused on objects. I write code organized around objects, not functions.
What is an object? Objects have traditionally been defined as data with methods (the object-oriented term for functions). Unfortunately, this is a very limiting way of looking at objects. I will look at a better definition of objects shortly (and again in Chapter 8, “Expanding Our Horizons”). When I talk about the data of an object, these can be simple things like numbers and character strings, or they can be other objects.
The advantage of using objects is that I can define things that are responsible for themselves. (See Table 1-2.) Objects inherently know what type they are. The data in an object allow it to know what state it is in and the code in the object allows it to function properly (that is, do what it is supposed to do).
In this case, the objects were identified by looking at the entities in the problem domain. I identified the responsibilities (or methods) for each object by looking at what these entities need to do. This is consistent with the technique of finding objects by looking for the nouns in the requirements and finding methods by looking for verbs. I find this technique to be quite limiting and will show a better way throughout the book. For now, it is a way to get us started.
The best way to think about what an object is, is to think of it as something with responsibilities. A good design rule is that objects should be responsible for themselves and should have those responsibilities clearly defined. This is why I say one of the responsibilities of a student object is knowing how to go from one classroom to the next.
I can also look at objects using the framework of Fowler's perspectives:
At the conceptual level, an object is a set of responsibilities.[4]
[4] I am roughly paraphrasing Bertrand Meyer's work of Design by Contract as outlined in Object-Oriented Software Construction, Upper Saddle River, N.J.: Prentice Hall, 1997, p. 331.
At the specification level, an object is a set of methods that can be invoked by other objects or by itself.
At the implementation level, an object is code and data.
Unfortunately, object-oriented design is often taught and talked about only at the implementation level—in terms of code and data—rather than at the conceptual or specification level. But there is great power in thinking about objects in these latter ways as well!
Since objects have responsibilities and objects are responsible for themselves, there has to be a way to tell objects what to do. Remember that objects have data to tell the object about itself and methods to implement functionality. Many methods of an object will be identified as callable by other objects. The collection of these methods is called the object's public interface.
For example, in the classroom example, I could write the Student object with the method gotoNextClassroom(). I would not need to pass any parameters in because each student would be responsible for itself. That is, it would know:
What it needs to be able to move
How to get any additional information it needs to perform this task
Initially, there was only one kind of student—a regular student who goes from class to class. Note that there would be many of these “regular students” in my classroom (my system). But what if I want to have more kinds of students? It seems inefficient for each student type to have its own set of methods to tell it what it can do, especially for tasks that are common to all students.
A more efficient approach would be to have a set of methods associated with all students that each one could use or tailor to their own needs. I want to define a “general student” to contain the definitions of these common methods. Then, I can have all manner of specialized students, each of whom has to keep track of his or her own private information.
In object-oriented terms, this general student is called a class. A class is a definition of the behavior of an object. It contains a complete description of:
The data elements the object contains
The methods the object can do
The way these data elements and methods can be accessed
Since the data elements an object contains can vary, each object of the same type may have different data but will have the same functionality (as defined in the methods).
To get an object, I tell the program that I want a new object of this type (that is, the class that the object belongs to). This new object is called an instance of the class. Creating instances of a class is called instantiation.
Writing the “Go to the next classroom” example using an object-oriented approach is much simpler. The program would look like this:
1. |
Start the control program. |
2. |
Instantiate the collection of students in the classroom. |
3. |
Tell the collection to have the students go to their next class. |
4. |
The collection tells each student to go to their next class. |
5. |
Each student:
|
4. |
Done. |
This works fine until I need to add another student type, such as the graduate student.
I have a dilemma. It appears that I must allow any type of student into the collection (either regular or graduate student). The problem facing me is how do I want the collection to refer to its constituents? Since I am talking about implementing this in code, the collection will actually be an array or something of some type of object. If the collection were named something like, RegularStudents, then I would not be able to put GraduateStudents into the collection. If I say that the collection is just a group of objects, how can I be sure that I do not include the wrong type of object (that is, something that doesn't do “Go to your next class”)?
The solution is straightforward. I need a general type that encompasses more than one specific type. In this case, I want a Student type that includes both RegularStudents and GraduateStudents. In object-oriented terms, we call Student an abstract class.
Abstract classes define what other, related, classes can do. These “other” classes are classes that represent a particular type of related behavior. Such a class is often called a concrete class because it represents a specific, or nonchanging, implementation of a concept.
In the example, the abstract class is Student. There are two types of Students represented by the concrete classes, RegularStudents and GraduateStudents. RegularStudent is one kind of Student and GraduateStudent is also a kind of Student.
This type of relationship is called an is-a relationship, which is formally called inheritance. Thus, the RegularStudent class inherits from Student. Other ways to say this would be, the GraduateStudent derives from, specializes, or is a subclass of Student.
Going the other way, “the Student class is the base class, generalizes, or is the superclass of GraduateStudent and of RegularStudent.
Abstract classes act as placeholders for other classes. I use them to define the methods their derived classes must implement. Abstract classes can also contain common methods that can be used by all derivations. Whether a derived class uses the default behavior or replaces it with its own variation is up to the derivation (this is consistent with the mandate that objects be responsible for themselves).
This means that I can have the controller contain Students. The reference type used will be Student. The compiler can check that anything referred to by this Student reference is, in fact, a kind of Student. This gives the best of both worlds:
The collection only needs to deal with Students (thereby allowing the instructor object just to deal with students).
Yet, I still get type checking (only Students that can “Go to their next classroom” are included).
And, each kind of Student is left to implement its functionality in its own way.
Abstract classes are more than classes that do not get instantiated.Abstract classes are often described as classes that do not get instantiated. This definition is accurate—at the implementation level. But that is too limited. It is more helpful to define abstract classes at the conceptual level. Thus, at the conceptual level, abstract classes are simply placeholders for other classes. That is, they give us a way to assign a name to a set of related classes. This lets us treat this set as one concept. In the object-oriented paradigm, you must constantly think about your problem from all three levels of perspective. |
Since the objects are responsible for themselves, there are many things they do not need to expose to other objects. Earlier, I mentioned the concept of the public interface—those methods that are accessible by other objects. In object-oriented systems, the main types of accessibility are:
This leads to the concept of encapsulation. Encapsulation has often been described simply as hiding data. Objects generally do not expose their internal data members to the outside world (that is, their visibility is protected or private).
But encapsulation refers to more than hiding data. In general, encapsulation means any kind of hiding.
In the example, the instructor did not know which were the regular students and which were the graduate students. The type of student is hidden from the instructor (I am encapsulating the type of student). As you will see later in the book, this is a very important concept.
Another term to learn is polymorphism.
In object-oriented languages, we often refer to objects with one type of reference that is an abstract class type. However, what we are actually referring to are specific instances of classes derived from their abstract classes.
Thus, when I tell the objects to do something conceptually through the abstract reference, I get different behavior, depending upon the specific type of derived object I have. Polymorphism derives from poly (meaning many) and morph (meaning form). Thus, it means many forms. This is an appropriate name because I have many different forms of behavior for the same call.
In the example, the instructor tells the students to “Go to your next classroom.” However, depending upon the type of student, they will exhibit different behavior (hence polymorphism).