0% found this document useful (0 votes)
18 views25 pages

Chapter 03

This document discusses object-oriented design principles like encapsulation, abstraction, and interfaces. It explains how to specify class methods, implement interfaces, extend interfaces, and use interfaces as data types. It also provides guidance on identifying classes, using CRC cards to describe responsibilities and collaborations, and designing classes for reusability using the Unified Modeling Language. The goal is to teach programmers how to effectively design classes and apply object-oriented concepts.

Uploaded by

gitu583
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
18 views25 pages

Chapter 03

This document discusses object-oriented design principles like encapsulation, abstraction, and interfaces. It explains how to specify class methods, implement interfaces, extend interfaces, and use interfaces as data types. It also provides guidance on identifying classes, using CRC cards to describe responsibilities and collaborations, and designing classes for reusability using the Unified Modeling Language. The goal is to teach programmers how to effectively design classes and apply object-oriented concepts.

Uploaded by

gitu583
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 25

Designing Classes

Chapter 3
Chapter Contents
Encapsulation
Specifying Methods
Java Interfaces
• Writing an Interface
• Implementing an Interface
• An Interface as a Data Type
• Type Casts Within an Interface Implementation
• Extending an Interface
• Named Constants Within an Interface
• Interfaces Versus Abstract Classes
Choosing Classes
• Identifying Classes
• CRC Cards
Reusing Classes 2
Encapsulation
Hides the fine detail of the inner workings of
the class
• The implementation is hidden
• Often called "information hiding"

Part of the class is visible


• The necessary controls for the class are left
visible
• The class interface is made visible
• The programmer is given only enough
information to use the class 3
Encapsulation

Fig. 3-1 An automobile's controls are visible to the


driver, but its inner workings are hidden.
4
Abstraction
A process that has the designer ask what
instead of why
• What is it you want to do with the data
• What will be done to the data

The designer does not consider how the


class's methods will accomplish their goals
The client interface is the what
The implementation is the how
5
Abstraction

Fig. 3-2 An interface


provides well-regulated
communication between a
hidden implementation and
a client.

6
Specifying Methods
Specify what each method does
Precondition
• Defines responsibility of client code

Postcondition
• Specifies what will happen if the preconditions
are met
Assertions can be written as comments to
identify design logic
// Assertion: intVal >= 0
7
Java Interface
A program component that contains
• Public constants
• Signatures for public methods
• Comments that describe them
Begins like a class definition
• Use the word interface instead of class

public interface someClass


{
public int someMethod();
}
8
Java Interface Example
public interface NameInterface
{ /** Task: Sets the first and last names.
* @param firstName a string that is the desired first name
* @param lastName a string that is the desired last name */
public void setName(String firstName, String lastName);
/** Task: Gets the full name.
* @return a string containing the first and last names */
public String getName();
public void setFirst(String firstName);

public String getFirst();


public void setLast(String lastName);

public String getLast();


public void giveLastNameTo(NameInterface child);

public String toString();


} // end NameInterface
9
Implementing an Interface
A class that implements an interface must state
so at start of definition
public class myClass implements someInterface

The class must implement every method


declared in the interface
Multiple classes can implement the same
interface
A class can implement more than one interface
An interface can be used as a data type
public void someMethod (someInterface x)

10
Implementing an Interface

Fig. 3-3 The files for an interface, a class that implements


the interface, and the client.
11
Type Casts Within an Interface
Implementation
In any class that implements an interface
• A parameter may be of type Object
• A type cast would probably be needed within that
method public class Pet implements Comparable
{ private String name;
private int age; // in years
private double weight; // in pounds

/** Task: Compares the weight of two pets. */


public int compareTo(Object other)
{ Pet otherPet = (Pet)other;
return weight - otherPet.weight;
} // end compareTo
< Other methods are here. >
} // end Pet
12
Extending an Interface
Use inheritance to derive an interface from
another
When an interface extends another
• It has all the methods of the inherited interface
• Also include some new methods

Also possible to combine several interfaces


into a new interface
• Not possible with classes

13
Named Constants Within an Interface

An interface can contain named constants


• Public data fields initialized and declared as
final
Consider an interface with a collection of
named constants
• Then derive variety of interfaces that can make
use of these constants

14
Interfaces Versus Abstract Classes
Purpose of interface similar to purpose of
abstract class
But … an interface is not a base class
• It is not a class of any kind

Use an abstract base class when


• You need a method or private data field that
classes will have in common
Otherwise use an interface
15
Choosing Classes
Look at a prospective system from a
functional point of view
Ask
• What or who will use the system
• What can each actor do with the system
• Which scenarios involve common goals

Use a case diagram

16
Choosing Classes

Fig. 3-4 A use case diagram for a registration system


17
Identifying Classes
Describe the system
• Identify nouns and verbs
Nouns suggest classes
• Students
• Transactions
• Customers
Verbs suggest appropriate methods
• Print an object
• Post a transaction
• Bill the customer
18
Identifying Classes

Fig. 3-5 A description of a use case for adding a course

19
CRC Cards
Index cards – each card represents one
class
Write a descriptive name for class at top
List the class's responsibilities
• The methods

Indicate interactions
• The collaborations

These are CRC cards


"Class-Responsibility-Collaboration" 20
CRC Cards

Fig. 3-6 A class-responsibility-collaboration card

21
Unified Modeling Language
Used to illustrate a system's classes and
relationships
Provides a class diagram
• Class name
• Attributes
• Operations

Fig. 3-7 A class representation that can


be part of a class diagram. 22
Unified Modeling Language

Fig. 3-8 UML notation for a base class


Student and two derived classes 23
Unified Modeling Language

Fig. 3-9 Part of a UML class diagram with associations.

24
Reusing Classes
Much software combines:
• Existing components
• New components

When designing new classes


• Plan for reusability in the future
• Make objects as general as possible
• Avoid dependencies that restrict later use by
another programmer

25

You might also like