Java Objects by Jacquie Barker

From the Publisher

This book is for anyone who wants to learn not only the Java 2 language, but also how to structure a problem properly from an object-oriented perspective. Even if you are already familiar with Java, this book will still be a valuable asset to you as you see an example case study evolve from its initial conception as an object model to implementation as a fully functional Java 2 application.

Author Biography: With over 20 years of experience as a software developer and project manager, Jacquie has spent the past nine years focusing on object technology, and has become proficient as a "hands on" object modeler and Sun Microsystems certified Java programmer. Jacquie is currently employed as a principal member of the technical staff at SRA International, Inc. in Fairfax, Virginia, where she consults for both public and private sector clients.

Product Details

• Table of Contents
• Read an Excerpt

Table of Contents

Read an Excerpt

Chapter 3: Objects and Classes

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....