Advanced Object-Oriented Concepts
3. Advanced Object-Oriented Concepts
Chapter 1, “Introduction to Object-Oriented Concepts,” and Chapter 2, “How to Think in Terms of Objects,” cover the basics of object-oriented (OO) concepts. Before we embark on our journey to learn some of the finer design issues relating to building an OO system, we need to cover a few more advanced OO concepts, such as constructors, operator overloading, and multiple inheritance. We also will consider error-handling techniques and the importance of understanding how scope applies to object-oriented design.
Some of these concepts might not be vital to understanding an OO design at a higher level, but they are necessary to anyone involved in the design and implementation of an OO system.
Constructors
Constructors may be a new concept for structured programmers. Although constructors are not normally used in non-OO languages such as COBOL, C, and Basic, the struct, which is part of C/C++, does include constructors. In the first two chapters, we alluded to these special methods that are used to construct objects. In some OO languages, such as Java and C#, constructors are methods that share the same name as the class. Visual Basic .NET uses the designation New and Objective-C uses the init keyword. As usual, we will focus on the concepts of constructors and not cover the specific syntax of all the languages. Let’s take a look at some Java code that implements a constructor.
For example, a constructor for the Cabbie class we covered in Chapter 2 would look like this:
public Cabbie(){ /* code to construct the object */ }
The compiler will recognize that the method name is identical to the class name and consider the method a constructor.
For example, if you include the following code in the class, the compiler will not consider this a constructor because it has a return value—in this case, an integer:
public int Cabbie(){ /* code to construct the object */ }
This syntax requirement can cause problems because this code will compile but will not behave as expected.
When Is a Constructor Called?
When a new object is created, one of the first things that happens is that the constructor is called. Check out the following code:
Cabbie myCabbie = new Cabbie();
The new keyword creates a new instance of the Cabbie class, thus allocating the required memory. Then the constructor itself is called, passing the arguments in the parameter list. The constructor provides the developer the opportunity to attend to the appropriate initialization.
Thus, the code new Cabbie() will instantiate a Cabbie object and call the Cabbie method, which is the constructor.
What’s Inside a Constructor?
Perhaps the most important function of a constructor is to initialize the memory allocated when the new keyword is encountered. In short, code included inside a constructor should set the newly created object to its initial, stable, safe state.
For example, if you have a counter object with an attribute called count, you need to set count to zero in the constructor:
count = 0;
The Default Constructor
If you write a class and do not include a constructor, the class will still compile, and you can still use it. If the class provides no explicit constructor, a default constructor will be provided. It is important to understand that at least one constructor always exists, regardless of whether you write a constructor yourself. If you do not provide a constructor, the system will provide a default constructor for you.
Besides the creation of the object itself, the only action that a default constructor takes is to call the constructor of its superclass. In many cases, the superclass will be part of the language framework, like the Object class in Java. For example, if a constructor is not provided for the Cabbie class, the following default constructor is inserted:
public Cabbie(){ super(); }
If you were to decompile the bytecode produced by the compiler, you would see this code. The compiler actually inserts it.
In this case, if Cabbie does not explicitly inherit from another class, the Object class will be the parent class. Perhaps the default constructor might be sufficient in some cases; however, in most cases, some sort of memory initialization should be performed. Regardless of the situation, it is good programming practice to always include at least one constructor in a class. If there are attributes in the class, it is always good practice to initialize them. Moreover, initializing variables is always a good practice when writing code, object-oriented or not.
It is not surprising that maintenance becomes an issue here. If you depend on the default constructor and then subsequent maintenance adds another constructor, the default constructor is no longer created. In short, the default constructor is added only if you don’t include any constructors. As soon as you include just one, the default constructor is not provided.
Using Multiple Constructors
In many cases, an object can be constructed in more than one way. To accommodate this situation, you need to provide more than one constructor. For example, let’s consider the Count class presented here:
public class Count { int count; public Count(){ count = 0; } }
On the one hand, we want to initialize the attribute count to count to zero: We can easily accomplish this by having a constructor initialize count to zero as follows:
public Count(){ count = 0; }
On the other hand, we might want to pass an initialization parameter that allows count to be set to various numbers:
public Count (int number){ count = number; }
This is called overloading a method (overloading pertains to all methods, not just constructors). Most OO languages provide functionality for overloading a method.
Overloading Methods
Overloading allows a programmer to use the same method name over and over, as long as the signature of the method is different each time. The signature consists of the method name and a parameter list (see Figure 3.1).
Figure 3.1. The components of a signature.
Thus, the following methods all have different signatures:
public void getCab(); // different parameter list public void getCab (String cabbieName); // different parameter list public void getCab (int numberOfPassengers);
By using different signatures, you can construct objects differently depending on the constructor used. This functionality is very helpful when you don’t always know ahead of time how much information you have available. For example, when creating a shopping cart, customers may already be logged in to their account (and you will have all of their information). On the other hand, a totally new customer may be placing items in the cart with no account information available at all. In each case, the constructor would initialize differently.
Using UML to Model Classes
Let’s return to the database reader example we used earlier in Chapter 2. Consider that we have two ways we can construct a database reader:
- Pass the name of the database and position the cursor at the beginning of the database.
- Pass the name of the database and the position within the database where we want the cursor to position itself.
Figure 3.2 shows a class diagram for the DataBaseReader class. Note that the diagram lists two constructors for the class. Although the diagram shows the two constructors, without the parameter list, there is no way to know which constructor is which. To distinguish the constructors, you can look at the corresponding code in the DataBaseReader class listed next.
Figure 3.2. The DataBaseReader class diagram.
Here is a code segment of the class that shows its constructors and the attributes that the constructors initialize (see Figure 3.3):
public class DataBaseReader { String dbName; int startPosition; // initialize just the name public DataBaseReader (String name){ dbName = name; startPosition = 0; }; // initialize the name and the position public DataBaseReader (String name, int pos){ dbName = name; startPosition = pos; }; .. // rest of class }
Figure 3.3. Creating a new object.
Note how startPosition is initialized in both cases. If the constructor is not passed the information via the parameter list, it is initialized to a default value, such as 0.
How the Superclass Is Constructed
When using inheritance, you must know how the parent class is constructed. Remember that when you use inheritance, you are inheriting everything about the parent. Thus, you must become intimately aware of all the parent’s data and behavior. The inheritance of an attribute is fairly obvious. However, how a constructor is inherited is not as obvious. After the new keyword is encountered and the object is allocated, the following steps occur (see Figure 3.4):
- Inside the constructor, the constructor of the class’s superclass is called. If there is no explicit call to the superclass constructor, the default is called automatically; however, you can see the code in the bytecodes.
- Each class attribute of the object is initialized. These are the attributes that are part of the class definition (instance variables), not the attributes inside the constructor or any other method (local variables). In the DataBaseReader code presented earlier, the integer startPosition is an instance variable of the class.
- The rest of the code in the constructor executes.
Figure 3.4. Constructing an object.
The Design of Constructors
As we have already seen, when designing a class, it is good practice to initialize all the attributes. In some languages, the compiler provides some sort of initialization. As always, don’t count on the compiler to initialize attributes! In Java, you cannot use an attribute until it is initialized. If the attribute is first set in the code, make sure that you initialize the attribute to some valid condition—for example, set an integer to zero.
Constructors are used to ensure that the application is in a stable state (I like to call it a “safe” state). For example, initializing an attribute to zero, when it is intended for use as a denominator in a division operation, might lead to an unstable application. You must take into consideration that a division by zero is an illegal operation. Initializing to zero is not always the best policy.
During the design, it is good practice to identify a stable state for all attributes and then initialize them to this stable state in the constructor.