This series, The Object-Oriented Thought Process, is intended for someone just learning an object-oriented language and wants to understand the basic concepts before jumping into the code or someone who wants to understand the infrastructure behind an OOP language they are already using. Click here to start at the beginning of the series.
In keeping with the code examples used in the previous articles, Java will be the language used to implement the concepts in code. One of the reasons that I like to use Java is because you can download the Java compiler for personal use at the Sun Microsystems Web site http://java.sun.com/. You can download the J2SE 1.4.2 SDK (software development kit) to compile and execute these applications and will provide the code listings for all examples in this article. I have the SDK 1.4.0 loaded on my machine. I will provide figures and the output (when appropriate) for these examples. See the previous articles in this series for detailed descriptions for compiling and running all the code examples in this series.
The last column continued the discussion on insuring that an object is created in a safe state. When designed properly, an object must be initialized properly and in no cases should the state of the object contribute to a program crash or the dissemination of incorrect data.
This article will explore the actual components of a class. In other words, what the class is really made of.
Class Internals
I have already covered the difference between the interface and the implementation of a class. No matter how well you think out the problem of what should be an interface and what should be part of the implementation, the bottom line always comes down to how useful the class is and how it interacts with other classes. A class should never be designed in a vacuum, for as might be said, no class is an island. When objects are instantiated, they almost always interact with other objects. An object also can be used within another object, or be inherited. This article can be thought of as a dissection of a class and offers some guidelines that you should consider when designing classes. You’ll examine a simple class and then take it apart piece by piece—using the cabbie example presented in an earlier column.
Class components to discuss include:
- Class name—How the class name is identified
- Comments—How to create comments to document your code
- Attributes—How to define attributes for use in the class
- Constructors—Special methods used to properly initialize a class
- Accessors—Methods that are used to control access to private attributes
- Public interface methods—How to define public interface methods
- Private implementation methods—How to define private implementation methods
This class is meant for illustration purposes only. Some of the methods are not fleshed out (meaning that there is no implementation) and simply present the interface.
The Name of the Class
Figure 1 shows the class that will be dissected. Plain and simple, the name of the class in the example, Cabbie, is the name located after the keyword class:
public class Cabbie {
}
The class Cabbie name is used whenever this class is instantiated.
Note: Remember that the convention for this series is to use Java syntax. The syntax might be somewhat different in C# or C++, and totally different in other O-O languages such as Smalltalk.
Comments
In Java and C#, there are actually three types of comments. In Java, the third comment type (/***/) relates to a form of documentation that Java provides. I will not cover this type of comment in this column. C# provides similar syntax to create XML documents.
The first comment is the old C-style comment, which uses /* (slash-asterisk) to open the comment and */ (asterisk-slash) to close the comment. This type of comment can span more than one line, and it’s important not to forget to use the pair of open and close comment symbols for each comment. If you miss the closing comment (*/), some of your code might be tagged as a comment and overlooked by the compiler. Here is an example of this type of comment used with the Cabbie class:
/*
This class defines a cabbie and assigns a cab
*/
The second type of comment is the // (slash-slash), which renders everything after it, to the end of the line, a comment. This type of comment spans only one line, so you don’t need to remember to use a close comment symbol, but you do need to remember to confine the comment to just one line and not include any live code after the comment. Here is an example of this type of comment used with the Cabbie class:
// Name of the cabbie
Figure 1: The sample class.
Attributes
Attributes represent the state of the object because they store the information about the object. For your example, the Cabbie class has attributes that store the name of the company, the name of the cabbie, and the cab assigned to the cabbie. For example, the first attribute stores the name of the company:
private static String companyName = “Blue Cab Company”;
Note here the two keywords, private and static. The keyword private signifies that a method or variable can be accessed only within the declaring object.
Hiding as Much Data as Possible
All the attributes in this example are private. This is in keeping with the design principle of keeping the interface design as minimal as possible. The only way to access these attributes is through the method interfaces provided (which we will explore later in this article).
The static keyword signifies that there will be only one copy of this attribute for all the objects instantiated by this class. Basically, this is a class attribute. Thus, even if 500 objects are instantiated from the Cabbie class, there will be only one copy in memory of the companyName attribute (see Figure 2).
Figure 2: Object memory allocation.
The second attribute, name, is a string that holds the name of the cabbie:
private String name;
This attribute is also private so that other objects cannot access it directly. They must use the interface methods.
The myCab attribute is a reference to another object. The class, called Cab, holds information about the cab, such as its serial number and maintenance records:
private Cab myCab;
Passing a Reference
It is likely that the Cab object was created by another object. Thus, the object reference would be passed to the Cabbie object. However, for the sake of this example, the Cab is created within the Cabbie object. Likewise, for the purposes of this example, you are not really interested in the internals of the Cab object.
Note that at this point, only a reference to a Cab object is created; there is no memory allocated by this definition.
Constructors
This Cabbie class contains two constructors. You know they are constructors because they have the same name as the class: Cabbie. The first constructor is the default constructor:
public Cabbie() {
name = null;
myCab = null;
}
Technically, this is not a default constructor. The compiler will provide a default constructor if you do not specify a constructor for this class. By definition, the reason it is called a default constructor here is because it is a constructor with no arguments. If you provide a constructor with arguments, the system will not provide a default constructor. The rule is that the default constructor is only provided if you provide no constructors.
In this constructor, the attributes Name and myCab are set to null:
name = null;
myCab = null;
The Nothingness of Null
In many programming languages, the value null represents a value of nothing. This might seem like an esoteric concept, but setting an attribute to nothing is a useful programming technique. Checking a variable for null can identify whether a value has been properly initialized. For example, you might want to declare an attribute that will later require user input. Thus, you can initialize the attribute to null before the user is actually given the opportunity to enter the data. By setting the attribute to null (which is a valid condition), you can check whether an attribute has been properly set.
As you know, it is always a good idea to initialize attributes in the constructors. In the same vein, it’s a good programming practice to then test the value of an attribute to see whether it is null. This can save you a lot of headaches later if the attribute or object was not set properly. For example, if you use the myCab reference before a real object is assigned to it, you will most likely have a problem. If you set the myCab reference to null in the constructor, you can later check to see whether myCab is still null when you attempt to use it. An exception might be generated if you treat an uninitialized reference as if it were properly initialized.
The second constructor provides a way for the user of the class to initialize the Name and myCab attributes:
public Cabbie(String iName, String serialNumber) {
name = iName;
myCab = new Cab(serialNumber);
}
In this case, the user would provide two strings in the parameter list of the constructor to properly initialize attributes. Notice that the my Cab object is actually instantiated in this constructor:
myCab = new Cab(serialNumber);
At this point, the storage for a Cab object is allocated. Figure 3 illustrates how a new instance of a Cab object is referenced by the attribute myCab. Using two constructors in this example demonstrates a common use of method overloading. Notice that the constructors are all defined as public. This makes sense because, in this case, the constructors are obvious members of the class interface.
Figure 3: The Cabbie object referencing an actual cab object.
Accessors
In most, if not all, examples in this series, the attributes are defined as private so that a second object cannot access another object’s attributes. It would be ridiculous to create an object in isolation—you want to share the appropriate information with other objects. Isn’t it necessary to inspect and sometimes change another class’s attribute? The answer is yes, of course. There are times when an object needs to access another object’s attributes; however, it does not need to do it directly.
A class should be very protective about its attributes. For example, you do not want object A to have the capability to inspect or change the attributes of object B without object B having control. There are several reasons for this; the most important reasons really boil down to data integrity and efficient debugging.
Assume that there is a bug in the Cab class. You have tracked the problem to the Name attribute. Somehow, it is getting overwritten, and garbage is turning up in some name queries. If Name were public and any class could change it, you would have to go searching through all the possible code, trying to find places that reference and change Name. However, if you let only a Cabbie object change Name, you’d only have to look in the Cabbie class. This access is provided by a type of method called an accessor. Sometimes, accessors are referred to as getters and setters, and sometimes they’re simply called get() and set(). By convention, in this series I’ll name the methods with the set and get prefixes, as in the following:
// Set the Name of the Cabbie
public void setName(String iName) {
name = iName;
}
// Get the Name of the Cabbie
public String getName() {
return name;
}
In this snippet, a Supervisor object must ask the Cabbie object to return its name (see Figure 4.4). The important point here is that the Supervisor object can’t simply retrieve the information on its own: it must ask the Cabbie object for the information. This concept is important at many levels. For example, you might have a setAge() method that checks to see whether the age entered was 0 or below. If the age is less than 0, the setAge() method can refuse to set this incorrect value. In general, the setters are used to ensure a level of data integrity.
Notice that the getCompanyName() method is declared as static, as a class method (as the name implies, class methods are owned by the class—not an individual object). Remember that the attribute companyName is also declared as static. A method, like an attribute, can be declared as static to indicate that there is only one copy of the method for the entire class.
Objects
Actually, there isn’t a physical copy of each non-static method for each object. Each object would point to the same physical code. However, from a conceptual level, you can think of objects as being wholly independent and having their own attributes and methods.
Figure 4: Asking for information.
The following code fragment illustrates how to define a static method, and Figure 5 shows how more than one object points to the same code.
Static Attributes
If an attribute is static, and the class provides a setter for that attribute, any object that invokes the setter will change the single copy. Thus, the value for the attribute will change for all objects.
// Get the Name of the Cabbie
public static String getCompanyName() {
return companyName;
}
Figure 5: Method memory allocation.
Public Interface Methods
Both the constructors and the accessor methods are declared as public, and are part of the public interface. They are singled out because of their specific importance to the construction of the class. However, much of the real work is provided in other methods. As mentioned in earlier articles, the public interface methods tend to be very abstract, and the implementation tends to be more concrete. For this class, you provide a method called giveDestination() that is the public interface for the user to describe where she wants to go:
public void giveDestination (){
}
What is inside of this method is not important at this time. The main point here is that this is a public method, and it is part of the public interface to the class.
Private Implementation Methods
Although all the methods discussed so far in this column are defined as public, not all the methods in a class are part of the public interface. Some methods in a class are meant to be hidden from other classes. These methods are declared as private:
private void turnRight(){
}
private void turnLeft() {
}
These private methods are simply meant to be part of the implementation, and not the public interface. You might ask who invokes these methods, if no other class can. The answer is simple—you might have already surmised that these methods are called internally from the class itself. For example, these methods could be called from within the method giveDestination:
public void giveDestination (){
... some code
turnRight();
turnLeft();
... some more code
}
The point here is that private methods are strictly part of the implementation, and are not accessible by other classes.
Conclusion
In this article, you have gotten inside a class and learned the fundamental concepts necessary to understand how a class is built. In future columns, you will continue to dissect more advanced components of class design.
References
Fowler, Martin. UML Distilled. Addison-Wesley Longman, 1997.
Gilbert, Stephen, and Bill McCarty. Object-Oriented Design in Java. The Waite Group, 1998.
Tyma, Paul, Gabriel Torok, and Troy Downing. Java Primer Plus. The Waite Group, 1996.
About the Author
Matt Weisfeld is an Assistant Professor at Cuyahoga Community College (Tri-C) in Cleveland,
Ohio. Matt is a part of the Information Technology department, teaching
programming languages such as C++, Java, and C# .NET as well as various Web
technologies. Prior to joining Tri-C, Matt spent 20 years in the information
technology industry gaining experience in software development, project
management, business development, corporate training, and part-time teaching.
Matt holds an MS in computer science and an MBA in project management.
