Chapter 1 ObjectOriented Concepts Basically a class consists

Chapter 1 Object-Oriented Concepts

Basically, a class consists of: 1) variables called fields together with 2) functions called methods that act on those fields.

An object – sometimes called an instance of a class – is a variable whose type is a class. An object has the fields and can call the methods of its class.

In Chap. 0, we studied WHAT a class does, not HOW the class does it. That is, we studied a class, namely, the String class, from the user’s perspective (method specifications) rather than from a developer’s perspective (fields and method definitions)

Principle of Data Abstraction: A user’s code should not access the implementation details of the class used.

Many of the classes we will study share the same method specifications.

When we abstract these specifications from the classes we get an interface. An interface consists of method specifications and constants only.

For example, here is an interface for the employees in a company. The information for each employee consists of the employee’s name and gross pay.

Note: Each constant and method is automatically public, and each method heading is followed by a semicolon.

To implement that interface, we will create a class with fields and, using those fields, definitions of at least the three methods specified in the interface.

/** * Returns the gross pay of this * Full. Time. Employee object. * * @return the gross pay of this * Full. Time. Employee object. * */ public double get. Gross. Pay() { return gross. Pay; } // method get. Gross. Pay

In a method definition, when a member (field or method) appears without an object reference, a reference to the calling object is assumed. To explicitly reference the calling object, use this.

Now, suppose we want to find the bestpaid full-time employee from a file of company employees, with each line in the file holding one employee’s name and gross pay. We create a Company class.

The Company class’s main method invokes the Company class’s run method on a newly constructed Company object. The find. Best. Paid method returns (a reference to) the Full. Time. Employee object with highest gross pay, or null if there were no employees scanned.

Exercise: Make up a sample input file, and determine the corresponding output.

Inheritance

Inheritance is the ability to define a new class that includes all the fields and some or all of the methods of an existing class.

Existing class = superclass New class = subclass SUPERCLASS SUBCLASS

The subclass may declare new fields and methods, and may override existing methods by giving them method definitions that differ from those in the super-class.

Example: Create an Hourly. Employee class of full-time hourly employees, with timeand-a-half for hours worked over 40. Information: Name, Hours worked, Pay rate

Modify Full. Time. Employee class?

The Open-Closed Principle Every class should be Open: extendible through inheritance Closed: stable for existing applications

Specifically, the Full. Time. Employee class should be stable for the existing application of finding the best-paid employee in a company. And extendible for any new applications!

The Hourly. Employee class will explicitly declare hours. Worked and pay. Rate fields (and, for convenience, regular. Pay and overtime. Pay fields). The name and gross. Pay fields are inherited from Full. Time. Employee.

But the name and gross. Pay fields in the Full. Time. Employee class had private visibility, so they could not be accessed outside of the Full. Time. Employee class.

What if we changed the visibility of the name and gross. Pay fields in the Full. Time. Employee class to public Then those fields could be accessed in the Hourly. Employee class, but … All user’s code can access them, DANGEROUS!

Instead, we change the visibility of the name and gross. Pay fields in the Full. Time. Employee class to protected Then those fields can be accessed in the Hourly. Employee class (as well as the Full. Time. Employee class), but not by all user’s code.