COSC2767: Object-Oriented
Programming
Haibin Zhu, Ph. D.
Professor of Computer Science
Nipissing University
1
Lecture 2
 Object-Oriented
Design,
Classes and Methods
2
Why Design ?
 Object-oriented
thinking begins with
object-oriented design
 It is the easiest way to give the student
an appreciation of the problems of
programming in the large (realistic
modern software development).
 Without understanding programming in
the large, one cannot understand the
importance of OOP
3
Activities in Software
Development
 Problem
Analysis
 Program Design
 Coding
 Documenting
 Testing
 Maintenance
4
Remember
Be clear about what you are trying to build.
 Successful software development is a long
term activity.
 The systems that we build tend to be at the
limit of the complexity that we and our tools
can handle.
 There are no cookbook methods that can
replace intelligence, experience, and good
taste in programming.

5
Remember
 Experimentation
is essential for all nontrivial software development.
 Design and programming are iterative
activities.
 The different phases of a software
project cannot be strictly separated.
 Programming and design cannot be
considered without also considering the
management of these activities.
6
Strategy
 There
is only one basic way to deal
with complexity: Divide and Conquer.
 Systems can be divided into
modules(Objects or Classes).
 The challenge is to ensure effective
communication between different parts
of the program without destroying the
divisions.
7
Objectives
We are concerned with producing software
that satisfies the users’ requirements.
 The primary means to do so is to produce
software with a clean internal structure.
 The Tasks of OO Design:

 To
specify:
The needed classes (or components)
 The interface

8
The Need for a Clean
Internal Structure
To simplify:
 Testing
 Porting
 Maintenance
 Extension
 Re-organization
 Understanding
9
Characteristics of
Successful Software
It has an extended life where it might be:
 worked on by succession of
programmers and designers
 ported to new hardware
 adapted to unanticipated uses
10
Some Issues of Design
Identify Components
 Postponing Decisions
 Preparing for Changes
 Coupling and Cohesion
 Two views of a Software System
 Formalize the Interface
 Naming
 Documentation

11
Identify Components
A component is simply an abstract entity that
can perform tasks or fulfill some
responsibilities.
 It may eventually be turned into a class, a
function, a module, or something else.
 A component must have a small, welldefined set of responsibilities.
 A component should interact with other
components to the minimal extent possible.

12
Postponing Decisions
Many decisions can be ignored for the
moment
 Only need to note that somehow the user
can manipulate

13
Preparing for Change





14
Your design team should also keep in mind that
change is inevitable. Users requirements change
with experience, hardware changes, government
regulations change.
Try to predict the most likely sources of change, and
isolate the effect. Common changes include
interfaces, file formats, communication protocols.
Isolate interfaces to hardware that is likely to
change.
Reduce dependency of one software component on
another.
Keep accurate record of the reasoning behind every
major decision in the design documentation.
Design for Change
 The
system must be designed to
remain as simple as possible under a
sequence of changes.
 We must aim for
 Flexibility
 Extensibility
 Portability
 OOD
15
can support the above.
Coupling and Cohesion

The separation of tasks into the domains of
different components should be guided by
the concepts of coupling and cohesion.
 Cohesion
is the degree to which the tasks
assigned to a component seem to form a
meaningful unit. Want to maximize cohesion.
 Coupling is the degree to which the ability to fulfill
a certain responsibility depends upon the actions
of another component. Want to minimize
coupling.
16
Parnas' Principles
The developer of a software component must
provide the intended user with all the
information needed to make effective use of
the services provided by the component, and
should provide no other information.
 The implementer of a software component
must be provided with all the information
necessary to carry out the given
responsibilities assigned to the component,
and should be provided with no other
information.

17
Public and Private View
 Public
view - those features (data or
behavior) that other components can see
and use
 Private view - those features (data or
behavior) that are used only within the
component
18
Formalize the Interface






19
The general structure of each component is
identified.
Components with only one behavior may be made
into functions.
Components with many behaviors are probably
more easily implemented as classes.
Names are given to each of the responsibilities these will eventually be mapped on to procedure
names.
Information is assigned to each component and
accounted for.
Scenarios are replayed in order to ensure all data is
available.
Naming
 The
selection of names is an important
task.
 Names
should be evocative in the context of
the problem.
 Names should be short.
 Names should be pronounceable (read them
out load).
 Names should be consistent within the
project.
 Avoid digits within a name.
20
Documentation
 The
user manual describes the
application as seen by the user.
 Quality
 System Design Documentation
21
User Manual
 Does
not depend upon the
implementation, so can be developed
before the implementation.
 Can naturally flow from the process of
walking through scenarios.
 Can be carried back to the clients to
make sure the users and the
implementers have the same ideas.
22
Quality
You should always remember that the
primary measure of quality is the degree to
which your customers (clients) are satisfied
with your product.
 Since often customers do not know exactly
what it is they want, it is important to work
with the client early in the design phase to
make sure the system your are developing is
the desired product. One very important way
to do this is to create the user manual even
before the software is written.

23
System Design
Documentation






24
Record the decisions made during the process of
system design.
Record the arguments for and against any major
decision, and the factors influencing the final choice.
Use graphs (UML) for the major components.
Maintain a log or diary of the process schedule.
Important to produce this while the ideas are fresh,
not in hindsight when many details will have been
forgotten.
Note the code only records the outcome of
decisions, not factors that lead up to decisions being
made.
Implement and Test
Subsystems
Classic techniques, such as stepwise
refinement, are used to implement each of
the subsystems.
 Subsystems are validated in isolation.

 Informal
proofs of correctness for the subsystem
are developed.
 Identify necessary conditions for correct
functioning. Try to minimize conditions, and test
input values whenever possible.
 Software testing is used as a confidence building
measure.
25
Integration and Testing
 Components
are slowly integrated into
completed system.
 Stubs can be used to perform testing all
during integration.
 Errors discovered during integration to
cause reinvestigation of validation
techniques performed at the subsystem
level.
26
Maintenance and
Evolution

Software does not remain fixed after the first working
version is released.






27
Errors or bugs can be discovered. Must be corrected.
Requirements may change. Say as a result of government
regulations, or standardization among similar products.
Hardware may change.
Users expectations may change. Greater functionality, more
features. Often as a result of competition from similar
products.
Better documentation may be required.
A good design recognizes the inevitability of change,
and plans an accommodation for these activities
from the very beginning.
Common Design Flaws

Direct modification



Too Much Responsibility (or services, methods)




Usually the result of designing software components without thinking about
how they will be used.
Misleading Names

28
Components with no responsibility serve no purpose.
Often arise when designers equate physical existence with logical design
existence.
Components with unused responsibility


Components with too much responsibility are difficult to understand and to
use.
Responsibility should be broken into smaller meaningful packages and
distributed.
No Responsibility


Components that make direct modification of data values in other
components are a direct violation of encapsulation.
Such coupling makes for inflexible designs.
Names should be short and unambiguously indicate what the
responsibilities of the component involve.
Classes and Methods
 Same
Ideas, Different Terms
 Encapsulation and Instantiation
 Internal and External Views
 Behavior and State
 Class Definitions
 Methods
 Variations on Classes
29
Same Ideas, Different
Terms

All OOP languages have the following
concepts, although the terms they use may
differ:
 classes,
object type, factory object
 instances, objects
 message passing, method lookup, member
function invocation, method binding
 methods, member function, method function
 inheritance, subclassing
30
Encapsulation and
Instantiation
Encapsulation - The purposeful hiding of
information, thereby reducing the amount of
details that need to be
remembered/communicated among
programmers.
 A Service View - The ability to characterise
an object by the service it provides, without
knowing how it performs its task.
 Instantiation - The ability to create multiple
instances of an abstraction.

31
Common Behavior and
State
A
class can also be viewed as a
combination of behavior and state.
 Behavior:
The actions that an instance
can perform in response to a request.
Implemented by methods.
 State: The data that an object must
maintain in order to successfully complete
its behavior. Stored in instance variables
(also known as data members, or data
fields).
32
Design Steps of OOD
 Find
the Concepts/Classes and their
most fundamental relationships.
 Refine the Classes by specifying the
sets of Operations on them
 classify
these operations: constructors,
destructors, etc.
 consider minimalism, completeness, and
convenience
33
Design Steps (cont’d)
 Refine
the classes by specifying their
dependencies on other classes:
 Inheritance
dependencies
 Composition dependencies
 Use dependencies
 Specify
the interfaces for the classes:
 separate
functions into public and protected
operations
 specify the exact type of the operations on
the classes.
34
Finding Classes
 Good
design must capture and model
some aspects of reality.
 Look at the application rather than the
computer abstractions.
 Usually nouns correspond to classes
and verbs represent functions.
 Discussions with experts in the
application domain.
35
Behavior and State

All classes can be characterized by two
aspects:
 The
behavior of an object class is the set of
actions a component can perform. The complete
set of behavior for an object is sometimes called
the protocol.
 The state of an object represents all the
information (data values) held within an object.

36
Notice that it is common for behavior to
change state. For example, the edit behavior
of a recipe may change the preparation
instructions, which is part of the state.
Example

37
When ordering new videotapes from a supplier, the
store manager creates a purchase order, fills in the
date, the supplier’s name , address, and enters a list of
videotapes to be ordered. The purchase order is added
to a permanent list of purchases. When one or more
video tapes are received from a supplier, a clerk
locates the original purchase order and makes a record
of each tape that was received. A record of the
videotape is then added to the store’s inventory. When
all tapes listed on a particular purchase order have
been received, the manager sends a payment to the
supplier and the purchase order is given a completion
date.
Specifying operations
Consider how an object of the class is
constructed, copied, and destroyed.
 Define the minimal set of operations required
by the concept the class is representing.
 Consider which operations could be added
for notational convenience and include only a
few really important ones.
 Consider which operations are to be virtual.
 Consider what commonality of naming and
functionality can be achieved across all the
classes of the component.

38
Operations on a Class

Foundation:


Selectors( or Accessors):


Operations that produce an object of another type based on
the value (state) of the object to which they are applied.
Iterators:

39
Operations that modify the state of an object.
Conversion Operators:


Operations that do not modify the state of an object.
Modifiers(or Setters):


Constructors and destructors
Operations that processes data members containing
collections of objects.
Specifying
Dependencies
 The
key dependencies to consider in
the context of design are inheritance
and use relationships.
 Overuse can lead to inefficient and
incomprehensible designs.
40
Specifying Interfaces
 Private
functions are not considered at
this stage.
 The interface should be implementation
independent (more than one
implementation should be possible).
 All operators in a class should support
the same level of abstraction.
41
Reorganizing the Class
Hierarchy
 Typically,
the initial organization of classes
may not be adequate and therefore, we
may have to reorganize to improve the
design and/or implementation.
 The two most common reorganizations of a
class hierarchy are
 factoring
of two classes into a new class
 splitting a class into two new ones.
42
Experimentation and
Analysis
 Prototyping
is frequently used for
experimenting.
 Different aspects of a system may be
prototyped independently, such as the
graphical user interface.
 Analysis of a design and/or
implementation can be an important
source of insight.
43
The Definition of Class
 Class
n
::=<n, d, m, x>, where
is an Identification or a name of the
class;
 d is the space description (template) for
memory;
 m is the set of methods (or services,
operations) the objects of this class can
make; and
 x is a unified interface of all the objects of
the class.
44
Class Definition in C++
class PlayingCard {
public:
enum Suits {Spade, Diamond, Club, Heart};
Suits suit () { return suitValue; }
int rank () { return rankValue; }
private:
Suits suitValue;
int rankValue;
};
45
Visibility Modifiers

The terms public and private are used to
differentiate the internal and external aspects
of a class.
 public
features can be seen and manipulated by
anybody -- they are the external (interface or
service) view.
 private features can be manipulated only within a
class. They are the internal (implementation)
view.

46
Typically methods are public and data fields
are private, but either can be placed in either
category.
Methods
A name that will be matched to a message to
determine when the method should be
executed.
 A signature, which is the combination of
return type and argument types. Methods
with the same name can be distinguished by
different signatures.
 A body, which is the code that will be
executed when the method is invoked in
response to a message.

47
Constructor








48
class PlayingCard {
// constructor, initialize new playing card
public PlayingCard (Suits is, int ir)
{ suit = is; rank = ir; faceUp = true; }
...
}
A constructor is a method that is used to initialize a
newly constructed object. In C++, Java, C# and
many other languages it has the same name as the
class.
More about constructors in the next lecture.
Accessor (or getter)
Methods

An accessor (or getter) is a method that simply
returns an internal data value:

class PlayingCard {
...
// operations on a playing card
public int rank
()
{ return rankValue; }
public Suits suit
()
{ return suitValue; }
...
private int rankValue;
}







49
Why Use an Accessor?
 You
can make the data field read-only.
 It provides better documentation that
the data field is accessible
 It makes it easier to later change the
access behavior (count number of
accesses, whatever).
50
Setters (or mutators)

A setter (sometimes called a mutator method) is a
method that is used to change the state of an object:

class PlayingCard {
// operations on a playing card
public void setFaceUp (boolean up) { faceUp =
up; }
...
// private data values
private boolean faceUp;
}






51
Order of Methods
 List
important topics first.
 Constructors are generally very
important, list them first.
 Put public features before private ones.
 Break long lists into groups
 List items in alphabetical order to make
it easier to search.
52

In C++:
class PlayingCard {
public:
...
Colors color () ;
...
};
PlayingCard::Colors PlayingCard::color ( )
{
// return the face color of a playing card
if ((suit == Diamond) || (suit == Heart))
return Red;
return Black;
}

Notice need for fully-qualified names.













53
Separation of Definition
and Implementation
Considerations in
Method Definitions
 In
C++ you have a choice to define a
method in the class interface, or
separately in an implementation file. How
do you decide?
 Readability.
Only put very small methods in
the class definition, so that it is easier to read.
 Semantics. Methods defined in class
interface may (at the discretion of the
compiler) be expanded in-line. Another
reason for only defining very small methods
this way.
54
Variations on Classes
 Interfaces
in Java (Methods without
Implementations)
 Nested classes in Java and C++
 Class Data fields
55
Properties
 Properties
are a way to define getters
and setters, but allow them to be used
as if they were simple assignments and
expressions:
 writeln ('rank is ', aCard.rank); (* rank is
property of card *)
 aCard.rank = 5; (* changing the rank
property *)
56
Inner or Nested Classes









57
C++ or Java
Whether the inner class can access features of the
outer class is different in different languages.
class LinkedList {
...
private class Link { // inner class
public int value;
public Link next;
}
}
Class Data Fields

Idea is that all instances of a class can share
a common data field. Simple idea, but how to
resolve the following paradox. All instances
have the same behavior:
 Either
they all initialize the common area, which
seems bad, or
 Nobody initializes the common area, which is also
bad.
 Different
languages use a variety of
mechanisms to get around this.
58
Java Class
class PlayingCard {
public int suit () { return suitValue; }
public int rank () { return rankValue; }
private int suitValue;
private int rankValue;
public static final int Spade = 1;
public static final int Diamond = 2;
public static final int Club = 3;
public static final int Heart = 4;
}
Note: Java also applies visibility modifiers to each item
individually. Does not have enumerated data types,
uses symbolic constants instead.
59
Template for Class
Definition
Import Statements
Class Comment
class
{
Class Name
Data Members
Methods
(incl. Constructor)
}
60
Data Member
Declaration
<modifiers>
<data type> <name> ;
Modifiers
Data Type
private
String
Name
ownerName ;
Note: There’s only one modifier in this example.
61
Method Declaration
<modifier>
<return type>
<method name>
( <parameters>
<statements>
}
Modifier
public
Return Type
void
setOwnerName
ownerName = name;
}
62
Method Name
(
String
Parameter
name
) {
Statements
){
Constructor

A constructor is a special method that is executed when a
new instance of the class is created.
public <class name> ( <parameters> ){
<statements>
}
Modifier
public
Class Name
Bicycle
Parameter
(
) {
ownerName = “Unassigned”;
}
63
Statements
The Definition of the
Bicycle Class
class Bicycle { // Data Member
private String ownerName;
//Constructor: Initialzes the data member
public Bicycle( ) {
ownerName = "Unknown";
}
//Returns the name of this bicycle's owner
public String getOwnerName( ) {
return ownerName;
}
//Assigns the name of this bicycle's owner
public void setOwnerName(String name) {
ownerName = name;
}
}
64
The Account Class
65
class Account {
private String ownerName;
private double balance;
public Account( ) {
ownerName = "Unassigned";
balance = 0.0;
}
public void add(double amt) {
balance = balance + amt;
}
public void deduct(double amt) {
balance = balance - amt;
}
public double getCurrentBalance( ) {
return balance;
}
public String getOwnerName( ) {
return ownerName;
}
public void setInitialBalance(double bal) {
balance = bal;
}
public void setOwnerName(String name) {
ownerName = name;
}
}
Using Bicycle and Account
public class Application2 {
//This sample program uses both the Bicycle and Account classes
public static void main(String[] args) {
Bicycle bike;
Account acct;
String myName = "Jon Java";
bike = new Bicycle( );
bike.setOwnerName(myName);
acct = new Account( );
acct.setOwnerName(myName);
acct.setInitialBalance(250.00);
acct.add(25.00);
acct.deduct(50);
//Output some information
System.out.println(bike.getOwnerName() + " owns a bicycle and");
System.out.println("has $ " + acct.getCurrentBalance() +" left in the bank");
}
}//Application2.java
66
Java Visibility Modifiers
 The
modifiers public and private designate the
accessibility of data members and methods.
 If a class component (data member or method)
is declared private, client classes cannot
access it.
 If a class component is declared public, client
classes can access it.
 Internal details of a class are declared private
and hidden from the clients. This is information
hiding.
67
Accessibility Example
…
Service obj = new Service();
class Service {
public int memberOne;
private int memberTwo;
public void doOne() {
obj.memberOne = 10;
…
obj.memberTwo = 20;
}
private void doTwo() {
obj.doOne();
…
obj.doTwo();
}
}
…
Client
68
Server
Data Members Should Be
private
 Data
members are the implementation
details of the class, so they should be
invisible to the clients. Declare them
private .
 Exception: Constants can (should) be
declared public if they are meant to be
used directly by the outside methods.
69
Guideline for Visibility
Modifiers

Guidelines in determining the visibility of data
members and methods:
 Declare
the class and instance variables private.
 Declare the class and instance methods private if
they are used only by the other methods in the
same class.
 Declare the class constants public if you want to
make their values directly readable by the client
programs. If the class constants are used for
internal purposes only, then declare them private.
70
Static and Final

Notice how symbolic constants are defined in
Java:
 static
means that all instances share the same
value. One per class. Similar meaning in many
languages.
 final is Java specific, and means it will not be
reassigned. (C++ has const keyword that is
similar).
 public static final int Spade = 1;
 public static final int Diamond = 2;
 public static final int Club = 3;
 public static final int Heart = 4;
71
Java Constants
class Dice {
private static final int MAX_NUMBER = 6;
private static final int MIN_NUMBER = 1;
private static final int NO_NUMBER = 0;
private int number;
public Dice( ) {
number = NO_NUMBER;
}
//Rolls the dice
public void roll( ) {
number = (int) (Math.floor(Math.random() *
(MAX_NUMBER - MIN_NUMBER + 1)) + MIN_NUMBER);
}
/Returns the number on this dice
public int getNumber( ) {
return number;
}
}
72
Summary
 Object-oriented
 Programming
Design
in the large
 Design
Steps
 Design Issues
 Class
and Methods
 Definition
 Visibilities
 Accessor
 Java
73
and setters
Classes and Methods
The End
Interesting materials at
http://stwww.weizmann.ac.il/g-cs/benari/home/software.html#java
74