1

CSC 413 - Software Development

2. Introduction to Object Oriented Programming

1/27/2018

John Roberts

2 It’s the first image that came up on my image tool for “roles” <shrug>
Overview
• Roles and Information

• Information Hiding

• Class Hierarchy

3 We’ll see this again when we focus on design a little more…

Roles and Information

• Roles

• the purpose(s) an object plays in a solution

• the responsibilities of these objects

• Information

• the data an object maintains to manage its roles

3
 4
Roles and Information

• Example: Professor and Student

• What are some of the roles and information of the

professor?

• What are some of the roles and information of the

student?

5 We’ll talk about those arrows in a minute

Roles and Information
Roles: lecture, answer questions,
add to course, give exam,
Professors give exercise, grade
Information:
grade spreadsheets,
courses this term,
students this term

Roles: study, do exercises,

signup for course, add, drop,
take exam, take notes
Information:
Students
courses completed,
courses this term, course notes 5

6
Overview
• Roles and Information

• Information Hiding

• Class Hierarchy

6
 7 Why is this bold?
Information Hiding

• In our Professor & Student example:

• Professor keeps the grade spreadsheets private

• Student can turn in an exercise, and the professor grades it and

enters it in the spreadsheet

• The Student isn’t concerned with HOW the Professor keeps

the spreadsheet, just that the exercise is graded and
recorded

• The Professor doesn’t get involved with HOW the Student

maintains course notes, just that notes are taken and
maintained

8
Information Hiding

• Focus on WHAT the roles are (and mean) but NOT HOW
they are implemented

• Helps deal with complexity - tell, don’t ask (tell an object

with a role to do its role, don’t worry about the details of
the role)

9
Information Hiding

• Instances of Professors
Jrob Kerry
lecture lecture
answer question answer question
grade spreadsheet grade spreadsheet
courses this term courses this term
students this term students this term

• Instances of Students
Monica Phil Shaka
study study study
do exercise do exercise do exercise
courses completed courses completed courses completed
courses this term courses this term courses this term

9
 10
Message Passing

• Monica (Phil, and Shaka) can send messages to Jrob

and Kerry - Jrob and Kerry are receivers of messages

• Messages consist of a receiver and associated

information used to process the message

• Where is the message processed?

10

11
Message Passing

• Jrob and Kerry have methods that will take the

information in the messages and perform a
computation based on this information

• The computation is performed in the body of a function -

the method - corresponding to the message

11

12
Message Passing

• The message originator is known as the client

• The message receiver is known as the server (provides a

service requested by the client)

12
 13
Classes and Instances

• Professor describes the roles, behaviors, services, and

responsibilities provided by the entire class of
Professors

• Jrob and Kerry are instances of Professor

• Jrob, Kerry, Monica, Phil, and Shaka are all instances of

their classes; they are objects capable of participating
in a computation

• There are typically many objects in an OO program. They

communicate by message passing to accomplish tasks
13

14 Now, with messages TM

Instances, Message Passing (Why not Class?) Why isn’t the word Class in the title? (except for where its in the title to remind
Jrob
lecture
me to ask this question) - Classes are templates; an instance must be created
to act or be acted on
Jrob answer question
grade spreadsheet
courses this term
students this term
Message: grade exercise

Message: do exercise
Monica
study
do exercise
Monica
courses completed
courses this term 14

15
Overview
• Roles and Information

• Information Hiding

• Class Hierarchy

15
 16 In this hierarchy, Professor is a subclass of Person. Usually true in reality as
Class Hierarchy well
• Organizes classes in a structured fashion to deal with
complexity
Superclass

Person
getName
getAge
getAddress

Name
Age
Address

Professor Student
lecture doExercise

AssistantProfessor FullProfessor Undergraduate GraduateStudent

serveOnCommittee evaluateAssistanttProfessor applyToGraduate doThesis

16
Subclasses

17
Class Hierarchy

• Class specifications (roles, information) provided at higher

levels (e.g. Person) are available for classes at lower levels
(e.g. Professor)

• We get to reuse roles and information

• Example: If Rachel is an instance of GraduateStudent,

we can pass her the getName method to get her Name

• We look for the getName method in the

GraduateStudent class, then Student, then
Person (where we find it, and so execute it)
17

18
Class Hierarchy

• Note that each Student will be an instance of either

Undergraduate or GraduateStudent, and each
Professor will be an instance of either
AssistantProfessor or FullProfessor

• We use Professor, Student, and Person for

specifying our hierarchy

• We define roles and information that ALL Persons have

in common in the Person class specification

• We will never directly create a Person instance

18
 19 We will revisit why “directly” is important here as we continue our discussion
Abstract Classes around OOP
• Classes used to specify common roles, behavior, and
data

• Will never create instances directly from these classes

19