You are here

Implementation in Java

6 June, 2016 - 12:54
Available under Creative Commons-ShareAlike 4.0 International License. Download for free at http://cnx.org/contents/402b20ad-c01f-45f1-9743-05eadb1f710e@37.6

Classes are the fundamental building blocks of Java programs. Defining a class is basically a matter of specifying a name for the class, its relationship to other classes and what sort of behaviors the class exhibits as well as what data it may contain.

SuppSuppose we wanted to define a class to describe a household pet. We could do it as such:

    class Pet { } 

The word class above is called a keyword and can only be used to state that the following code is the definition of a class. The class keyword is immediately followed by the desired name of the class, Crayon here. The curly braces, {...}, indicate the extent of the definition of the class. That is, any definitions of the class's behaviors and data will be found between the curly braces. Curly braces must therefore always appear as a matched set.

In general, in Java, curly braces mark the extent of a definition.

Note: The accepted typographic standard in the Java community is that the opening curly brace is at the end of a line and the ending curly brace is at the beginning of its own line. Any code between the curly braces is indented.

Well, our class for pets is simple, but not very interesting because it doesn't do anything. We could say that our pet has a name, but personally, I have found that the behavior of most pets is not affected by the particular name we give them. That is, we can give our pet a name but that doesn't change the way they behave. Let's try something else.

Pets eat a certain amount of food per day. Pets have a certain weight. Let's create a model, that states that the number of hours that a pet sleeps per day is related to the amount of food they eat and their weight. Thus we could say that a pet has a behavior of sleeping a certain number of hours depending on its weight and the amount of food eaten.

    /** * A class that models a household pet */ class Pet{ 

    /**     * The weight of the pet in lbs     */     double weight; 

    /**       *  The number of hours the pet will sleep after eating       *  the given lbs of food.       *  @param lbsOfFood The number of lbs of food eaten.       *  @return The number of hours slept after eating the food.       */     double hoursSlept(double lbsOfFood) {       return 24.0*lbsOfFood1weight;     } } 

But what about the pet's owner (a person, supposedly)? A person is not such a simple thing as a weight. Assigning a number to every possible person in the world is possible but not necessarily the most practical technique. There are many ways to represent people: the Registrar likes to think of you as a number with credit hours and unpaid bills, The CS department sees you as a 8-character login and unfinished graduation requirements, your doctor sees you as a collection of pulsating blood vessels, cells and bones, and your parents see you as this sweet little thing just out of diapers. A person is still a person, but the way that we choose to represent them may differ from situation to situation.

But here's the crux of the issue: does your pet care how you are internally represented? Or does your pet just want something that is a person to be their owner?

    /** * A class that models a household pet */ class Pet{ 

/** * The weight of the pet in lbs   */double weight; 

/**  * The pet's owner  */ Person owner; 

/**  *  The number of hours the pet will sleep after eating  *  the given lbs of food.  *  @param lbsOfFood The number of lbs of food eaten.  *  @return The number of hours slept after eating the food.  */ double hoursSlept(double lbsOfFood) {  return 24.0*lbsOfFood1weight; } 

/** *  Determines whether or not this pet is happy to see a *  particular person. *  @param p The person who the pet sees. *  @return true if the Person is their owner, false otherwise. */ boolean isHappyToSee(Person p) {     return p == owner;   } } 

Here we've added a field of type Person, which is a class used to represent people. It doesn't matter how Person is implemented, just that it is a representation of a person. We could use the class definition of Person that was created in the module on Abstraction, or perhaps one that is fixed up a little bit, or perhaps a completely new one. The Pet doesn't care.

Thus we see that objects can contain objects. What does this say about the possible complexity of a system of objects?