Read an Excerpt
Chapter 3: Objects and Classes
Objects are the fundamental building blocks of an object-oriented (OO) system. Just as abstraction involves producing a model of the real world as we discussed in Chapter 2, objects are 'mini abstractions' of various real-world components.In this chapter, you will learn:
- What makes up a software object
- How we use classes to specify an object's data and behavior
- How we create objects based on a class definition
- How objects keep track of one another
What Is An Object?
Before we talk about software objects, let's talk about real-world objects in general. According to Merriam-Webster's dictionary, an object is:
"(1) Something material that may be perceived by the senses; (2) something mental or physical toward which thought, feeling, or action is directed."
The first part of this definition refers to objects as we typically think of them: as physical 'things' that we can see and touch, and which occupy space. Because we intend to use the Student Registration System (SRS) case study as the basis for learning about objects throughout this book, let's think of some examples of physical objects that make sense in the general context of an academic setting, namely:
- The students who attend classes
- The professors who teach them
- The classrooms in which class meetings take place
- The furniture in these classrooms
- The buildings in which the classrooms are located
- The textbooks students use
and on and on. Of course, while all of these objects are commonly found on a typical collegecampus, not all of them are relevant to registering students for courses, nor are they all necessarily called out by the SRS case study; but, we won't worry about that for the time being. In Part 2 of this book, we'll learn a technique for using a requirements specification as the basis for identifying which objects are relevant to a particular abstraction.
Now, let's focus on the second half of the definition, particularly on the phrase 'something mental …toward which thought, feeling, or action is directed'. There are a great many conceptual objects that play important roles in an academic setting; some of these are:
- The courses that students attend
- The departments that faculty work for
- The degrees that students receive
and, of course, many others. Even though we can't see, hear, touch, taste, or smell them, conceptual objects are every bit as important as physical objects are in describing an abstraction.
Let's now get a bit more formal, and define a software object:
"A (software) object is a software construct that bundles together data (state) and functions (behavior) which, taken together, represent an abstraction of a 'real-world' (physical or conceptual) object."
Let's explore the two sides of objects - their state and behavior - separately, in more depth.
Data/State/Attributes
If we wish to record information about a student, what data might we require? Some examples might be:
- The student's name
- Their student ID and/or social security number
- The student's birthdate
- His or her address
- The student's designated major field of study, if they have declared one yet
- His or her cumulative grade point average (GPA)
- Who the student's faculty advisor is
- A list of the courses that the student is currently enrolled in this semester (a.k.a. the student's current course load)
- A history of all of the courses that the student has taken to date, the semester/year in which each was taken, and the grade that was earned for each: in other words, the student's transcript
and so on. Now, how about for a course? Perhaps we'd wish to record:
- The course number (for example, 'ART 101')
- The course name (for example, 'Introductory Basketweaving')
- A list of all of the courses which must have been successfully completed by a student prior to allowing that student to register for this course (i.e. the course's prerequisites)
- The number of credit hours that the course is worth
- A list of the professors who have been approved to teach this course
In object nomenclature, the data elements used to describe an object are referred to as the object's attributes.
An object's attribute values, when taken collectively, are said to define the state, or condition, of the object. For example, if we wanted to determine whether or not a student is 'eligible to graduate' (a state), we might look at a combination of:
- The student's transcript (an attribute), and
- The list of courses they are currently enrolled in (a second attribute)
to see if the student indeed is expected to have satisfied the course requirements for their chosen major field of study (a third attribute) by the end of the current academic year.
A given attribute may be simple - for example, 'GPA', which can be represented as a simple floating point number - or complex - for example, 'transcript', which represents a rather extensive collection of information with no simple representation.
Behavior/Operations/Methods
Now, let's revisit the same two types of object - a student and a course - and talk about these objects' respective behaviors. A student's behaviors (relevant to academic matters, that is!) might include:
- Enrolling in a course
- Dropping a course
- Choosing a major field of study
- Selecting a faculty advisor
- Telling you his or her GPA when asked
- Telling you whether or not he or she has taken a particular course, and if so, when the course was taken, which professor taught it, and what grade the student received.
It is a bit harder to think of an inanimate, conceptual object like a course as having behaviors, but if we were to imagine a course to be a living thing, then we can imagine that a course's behaviors might include:
- Permitting a student to register
- Determining whether or not a given student is already registered
- Telling you how many students have registered so far, or conversely, how many seats remain before the course is full
- Telling you what its prerequisite courses are
- Telling you how many credit hours it is worth
- Telling you which professor is assigned to teach the course this semester
and so on.
When we talk about software objects specifically, we define an object's behaviors, also known as its operations, as both the things that an object does to access its data (attributes) and the things that an object does to modify/maintain its data (attributes)
If we take a moment to reflect back on the behaviors we expect of a student as listed above, we see that each operation involves one or more of the student's attributes. For example:
- Telling you his or her GPA involves accessing the value of the student's 'GPA' attribute
- Choosing a major field of study updates the value of the student's 'major' attribute
- Enrolling in a course updates the value of the student's 'course load' attribute
Since we recently learned that the collective set of attribute values for an object defines its state, we now can see that operations are capable of changing an object's state.
Let's say that we define the state of a student who has not yet selected a major field of study as an 'undeclared' student. Asking a student object representing an 'undeclared' student to perform its 'choosing a major field of study' method will cause that object to update the value of its 'major field of study' attribute to reflect the newly selected major field. This then changes the student's state from 'undeclared' to 'declared'.
Yet another way to think of an object's operations are as services that can be requested of the object. For example, one service that we might call upon a course object to perform is to provide us with a list of all of the students who are currently registered for the course (a.k.a. a student roster).
When we actually get around to programming an object in a language like Java, we refer to the programming language representation of an operation as a method, whereas, strictly speaking, the term 'operation' is typically used to refer to a behavior conceptually. However, these two terms are often used interchangeably, and we'll do so throughout the rest of this book....
Very easy to understand and read. I have a much more clear understanding of objects and how to design and diagram them. I really like how the book takes you through the steps to transform a UML model to actual code. Before reading the book I had a frustrating time completing even simple programs. Now, I have a better understanding how to abstract a problem into its component objects. I completed my first small program, a simple time tracking system with graphical user interface (GUI), in record time.
This book also does at nice job at describing how to add a GUI to an application and how to make objects with file persistence.
This book is not a Java Language reference. However, it does cover the basic constructs of the language. I would recommend using this book as a guide to get your project from start to finish using objects and UML. You might want to also pickup a reference book that will help you answer the question of ¿How does the Date, Calendar and DateFormat classes work when trying to parse a String date/time into a Calendar object?¿