Object-Oriented Analysis and Design

01.Object-Oriented Paradigm.1

Chun-Han Lin (林均翰)

CSIE, NTNU
 Key Points 1

• Goals

• Design Methods

• Simple Problem: Display Shapes

• Functional Decomposition

• Problems of Functional Decomposition

Prof. Chun-Han Lin, CSIE, NTNU

2
 Goals

• Introduce an OO paradigm
• Contrast it with a functional decomposition
• Discuss important concepts of OO programming

• Discuss the differences between abstraction and

encapsulation
• This is very important.

• Address the problem of requirements and the need to

deal with changes

Prof. Chun-Han Lin, CSIE, NTNU

3
 Design Methods

• Ways of solving problems

• Structured design/programming (a.k.a. functional

decomposition)
• Think in terms of steps
• Functional programming (a.k.a. declarative
programming)
• Think in terms of functions and their composition
• OO design/programming
• Think in terms of objects that do things

Prof. Chun-Han Lin, CSIE, NTNU

4
 Simple Problem: Display Shapes

• Functional decomposition breaks the problem into

small steps.
• Connect to a database
• Locate and retrieve shapes
• Sort the shapes (perhaps by z-order; draw
background shapes first)
• Loop through the list and display each shape
• Identify a shape (circle, triangle, square?)
• Get the location of the shape
• Call functions to display the shape at the given location
Prof. Chun-Han Lin, CSIE, NTNU
5
 Functional Decomposition

• Decompose big problems into the functional steps required

to solve it
• For a very big problem, simply breaking it down to
smaller problems, then decomposing smaller problems
into functional steps.
• The goal is to slice up the problems until they are at a level
of granularity that is easy to solve in a couple of steps.
• Then, arranging the steps into an order that solves all of
the identified sub problems, and the big problem is
solved along the way.
• An extremely natural approach to problem solving; we do
this almost without thinking about it.
Prof. Chun-Han Lin, CSIE, NTNU
6
 Problems of Functional Decomposition

• There are two main problems with this approach to

design.
• It creates designs centered around a main program.
• The program is in control and knows all of the details
about what needs to be done and all of the details about
the program’s data structures.
• It creates designs that do not respond well to change
requests.
• These programs are not well modularized and so a change
request often requires modifications of the main program.
• E.g., a minor change in a data structure might cause
impacts throughout the entire main program.
Prof. Chun-Han Lin, CSIE, NTNU
7
 Review 1

• Goals

• Design Methods

• Simple Problem: Display Shapes

• Functional Decomposition

• Problems of Functional Decomposition

Prof. Chun-Han Lin, CSIE, NTNU

8
Object-Oriented Analysis and Design
01.Object-Oriented Paradigm.2

Chun-Han Lin (林均翰)

CSIE, NTNU
 Key Points 2

• With Respect to Change …

• Why Do The Problems Exist?

• Why Should We Care?

• Start of a Journey

Prof. Chun-Han Lin, CSIE, NTNU

10
 With Respect to Change …

• A process-based approach to solving problems does not

lead to program structures that can gracefully react to
change.
• Changes in software development often involves a
variation on an existing theme.
• Display new types of shapes
• Change the way shapes are rendered
• Add a new functionality to the program such as being
able to move the shapes after they have been displayed
• In main programs, the types of changes typically cause
complexity to increase and require that lots of files have to
be recompiled.
Prof. Chun-Han Lin, CSIE, NTNU
11
 Why Do The Problems Exist?

• The problems occur with the functional decomposition

approach because the resulting software exhibits …
• Poor use of abstraction
• Poor encapsulation (a.k.a. information hiding)
• Poor modularity
• If you have poor abstractions and you want to add
another one, it’s often not clear how to do it (easily).
• If you have poor encapsulation and poor modularity,
changes tend to percolate through the code since
nothing prevents dependencies from forming
throughout the code.
Prof. Chun-Han Lin, CSIE, NTNU
12
 Why Should We Care?

• As the book says …

• Many bugs originate with changes to the code.
• Things change. They always do. And nothing you
can do will stop change [from occurring to your
software system].
• We need to ensure that we do not get overcome by
change requests, so we create designs that are resilient
to change.
• Indeed, we want software designs that are designed to
accommodate change in a straightforward manner;
that is what OO analysis and design (OOAD) provides!
Prof. Chun-Han Lin, CSIE, NTNU
13
 Start of a Journey (1/4)

• What is the difference between abstraction and

encapsulation?

• How would you interpret the following statements if

you heard them in casual (admittedly nerdy)
conversation?
• That sound processing package offers a great set of
abstractions!
• Wow, that Employee class is horrible! There is no
encapsulation!
Prof. Chun-Han Lin, CSIE, NTNU
14
 Start of a Journey (2/4)

• Identify which concept, abstraction or encapsulation,

applies to the following statements
1. I wonder if Java’s Map class will do what I need?
2. I wonder if I can prevent users of my library from
finding out that MyClass.id is implemented as a
floating point number?
3. I like how I can decide at run time whether my List
variable will point at an instance of LinkedList or
ArrayList! I mean List’s API is fine but it’s nice to
know that I have the flexibility of picking the more
efficient implementation when my list size is small.

Prof. Chun-Han Lin, CSIE, NTNU

15
 Start of a Journey (3/4)
• Simple definitions
• Abstraction refers to the set of concepts that some entity
provides you in order for you to achieve a task or solve a
problem.
• The public methods of Java’s String class
• Encapsulation refers to a set of language-level mechanisms or
design techniques that hide implementation details of a class, a
module, or a subsystem from other classes, modules, and
subsystems.
• In most OO programming languages, marking an instance
variable “private” ensures that other classes cannot access
the value of that variable directly. They need to make use of
a method in order to retrieve or update that particular
internal variable.

Prof. Chun-Han Lin, CSIE, NTNU

16
 Start of a Journey (4/4)

• So, why do we want the things?

• Why do we want good abstractions?
• Why do we want good use of encapsulation?
• Let’s transition back to design methods.
• Discussion of analysis and requirements
• Additional problems with the functional
decomposition
• Cohesion and coupling
• OO approach

Prof. Chun-Han Lin, CSIE, NTNU

17
 Review 2

• With Respect to Change …

• Why Do The Problems Exist?

• Why Should We Care?

• Start of a Journey

Prof. Chun-Han Lin, CSIE, NTNU

18
Object-Oriented Analysis and Design
01.Object-Oriented Paradigm.3

Chun-Han Lin (林均翰)

CSIE, NTNU
 Key Points 3

• Analysis

• Requirements

• Problems of Requirements

Prof. Chun-Han Lin, CSIE, NTNU

20
 Analysis

• Analysis is the phase of software development that …

• Occurs before design when starting from scratch
• Occurs first when responding to a change request
during the maintenance of an existing system
• Its primary goal is to answer the following question.
• What is the problem that needs to be solved?
• Design is the phase that comes after analysis and its
goal is …
• How am I going to solve the problem?

Prof. Chun-Han Lin, CSIE, NTNU

21
 Requirements

• Requirements for a software system are initially

generated during the analysis phase of software
development and are, typically …
• Simple statements of desired functional capabilities
• The system should allow its users to sort records by
priority.
• Statements of non-functional capabilities
• The system should support 10,000 simultaneous users.
• Statements of constraints that must be met
• The system will comply with regulation XYZ at all times.

Prof. Chun-Han Lin, CSIE, NTNU

22
 Problems of Requirements (1/4)

• The problem?
• Experienced developers will tell you that …
• Requirements are incomplete and do not tell the whole
story.
• Requirements are typically wrong.
• Factually wrong or become obsolete
• Requirements and users are misleading.
• In addition, users may be non-technical and may not
understand the range of options that could solve their
problem.
• Their ill informed suggestions may artificially constrain
the space of solutions.

Prof. Chun-Han Lin, CSIE, NTNU

23
 Problems of Requirements (2/4)

• The other problem with requirements is that

requirements always change.
• They change because …
• A user’s needs change over time.
• As they learn more about a new problem domain, a
developer’s ability to generate better solutions to
the original problem (or the current problem if it
has evolved) will increase.
• The system’s environment changes.
• New hardware, new external pressures, new
techniques, …

Prof. Chun-Han Lin, CSIE, NTNU

24
 Problems of Requirements (3/4)

• Many developers view changing requirements as a bad

thing, and few design their systems to be resilient in the
face of change.
• Luckily, this view is changing.
• Agile software methods tell developers to welcome
change.
• They recommend a set of techniques, technologies, and
practices for developers to follow to remove the fear of change.
• OO analysis, design, and programming techniques
provide you with powerful tools to handle change to
software systems in a straightforward manner.

Prof. Chun-Han Lin, CSIE, NTNU

25
 Problems of Requirements (4/4)

• However, this does not mean that we stop writing requirements.

• They are incredibly useful despite the problems.
• The lesson here is that we need to improve the way we
design our systems and write our code such that changes can
be managed.
• Agile methods make use of user stories; other life cycle methods
make use of requirements documents or use cases (dressed-up
scenarios that describe desired functional characteristics of the
system).
• Once we have these things, and the understanding of the
problem domain that they convey, we then have to design
our system to address the requirements while leaving room
for the requirements to change.

Prof. Chun-Han Lin, CSIE, NTNU

26
 Review 3

• Analysis

• Requirements

• Problems of Requirements

Prof. Chun-Han Lin, CSIE, NTNU

27
Object-Oriented Analysis and Design
01.Object-Oriented Paradigm.4

Chun-Han Lin (林均翰)

CSIE, NTNU
 Key Points 4

• Problem with Functional Decomposition

• Cohesion

• Coupling

• Ripple Effects

Prof. Chun-Han Lin, CSIE, NTNU

29
 Problem with Functional Decomposition

• The book highlights problems with the code developed

with functional decomposition.
• Such code has weak cohesion and tight coupling.
• Translation: it does too many things and has too
many dependencies.
• Example
void process_records(records: record_list){
// sort records, update values in records, print records,
archive records, log each operation as it is performed, …
}
Prof. Chun-Han Lin, CSIE, NTNU
30
 Cohesion

• Cohesion is how closely operations in a routine are related.

• A simplification is that we want a method to do just one
thing, or we want a module to deal with just one thing.
• We want the code to exhibit strong cohesion.
• Methods: a method performs one operation.
• Classes: a class achieves a fine-grain design or
implementation goal.
• Packages: a package achieves a medium-grain design
goal.
• Subsystems: a subsystem achieves a coarse-grain design
goal.
• System: a system achieves all design goals and meets its
requirements.
Prof. Chun-Han Lin, CSIE, NTNU
31
 Coupling

• Coupling is the strength of a connection between two

routines.
• It is a complement to cohesion.
• Weak (strong) cohesion implies strong (loose)
coupling.
• With strong coupling, a single change in a method or
data structure will cause ripple effects, that is,
additional changes in other parts.
• We want systems with highly cohesive and loosely
coupled parts.
Prof. Chun-Han Lin, CSIE, NTNU
32
 Ripple Effects

• Ripple effects cause us to spend a long time doing

debugging and system understanding tasks.
• We make a change and unexpectedly something
breaks.
• This is called an unwanted side effect.
• If we have tightly coupled code, we discover that
many parts depended on the changed code.
• It takes time to discover and understand the
relationships.
• Once understanding is achieved, it often takes very
little time to actually fix the bug.
Prof. Chun-Han Lin, CSIE, NTNU
33
 Review 4

• Problem with Functional Decomposition

• Cohesion

• Coupling

• Ripple Effects

Prof. Chun-Han Lin, CSIE, NTNU

34
Object-Oriented Analysis and Design
01.Object-Oriented Paradigm.5

Chun-Han Lin (林均翰)

CSIE, NTNU
 Key Points 5

• OO Paradigm

• Comparisons

• Benefits of 2nd Scenario

• Revisiting the Shape System

Prof. Chun-Han Lin, CSIE, NTNU

36
 OO Paradigm (1/2)

• Rather than a main program do everything

• Populate a system with objects that can do things
themselves
• Scenario: You are an instructor at a conference. Your
session is over and now conference attendees need to go to
their next session.
• With functional decomposition, you would develop a
program to solve the problem that you, the instructor,
do everything.
• Get the roster, loop each attendee, look up the next
session, find its location, generate a route, and, finally,
tell the attendee how to go to the next session
• You do everything, attendees do (almost) nothing.

Prof. Chun-Han Lin, CSIE, NTNU

37
 OO Paradigm (2/2)

• The book asks would you do this in real life?

• And, the answer is (hopefully) No!
• What would you do instead?
• You would assume that everyone has a conference
program, knows where he needs to be next, and will go
to there on his own.
• All you would do is to end the session and head off to
the next activity.
• At worst, you would have a list of sessions at the front
of the class, and tell everyone to use the information to
locate the next session.

Prof. Chun-Han Lin, CSIE, NTNU

38
 Comparisons

• In 1st scenario
• You know everything, you are responsible for
everything, if something changes you would be
responsible for handling it.
• You give explicit instructions to each entity in the
system.
• In 2nd scenario
• You expect other entities to be self sufficient.
• You give general instructions and expect other entities
to know how to apply the instructions to their specific
situation.

Prof. Chun-Han Lin, CSIE, NTNU

39
 Benefits of 2nd Scenario

• The biggest benefit is that entities have their own

responsibilities.
• Indeed the approach represents a shift of responsibility
away from a central program to entities themselves.
• Suppose we had attendees and volunteers in our session, and the
volunteers have to do something between sessions.
• In the 1st approach, the session leader needs to know the
special case, and tell the volunteers to do it.
• In the 2nd approach, the session leader tells each person that
goes to your next session, and the volunteers will
automatically handle the special case without the session
leader knowing anything.
• Add new types of attendees without impacting the leader.
Prof. Chun-Han Lin, CSIE, NTNU
40
 Revisiting the Shape System

• Recall our display shapes program from earlier in the

lecture.

• How would you rearrange it to follow this new

approach?
• Homework!

Prof. Chun-Han Lin, CSIE, NTNU

41
 Review 5

• OO Paradigm

• Comparisons

• Benefits of 2nd Scenario

• Revisiting the Shape System

Prof. Chun-Han Lin, CSIE, NTNU

42
Object-Oriented Analysis and Design
01.Object-Oriented Paradigm.6

Chun-Han Lin (林均翰)

CSIE, NTNU
 Key Points 6

• OO Paradigm

• Object Responsibilities

Prof. Chun-Han Lin, CSIE, NTNU

44
 Foreshadowing

• The benefits discussed are inherent in the OO approach to

analysis, design, and implementation that we will learn in
this semester.
• Self-sufficient entities → objects
• Give general instructions → code to an interface
• Expect entities to apply general instructions to their
situation → polymorphism and subclasses
• Add new attendees without impacting the leader →
code to an interface, polymorphism, and subclasses
• Shift of responsibility → functionality distributed
across objects

Prof. Chun-Han Lin, CSIE, NTNU

45
 As an aside ...

• OO main programs tend to be short.

• Give a order to create an object and send a message
to it.
• Main programs in Android
• Completely hidden from Android developers
• Instead, in an application manifest, you specify an
initial activity.
• When your application launches, the activity’s
onCreate() method is automatically called.

Prof. Chun-Han Lin, CSIE, NTNU

46
 OO Paradigm

• OOAD is centered around the concept of objects.

• It produces systems that are networks of objects
collaborating to fulfill the responsibilities (requirements)
of the system.
• Objects are conceptual units that combine both data
and behavior (a.k.a features).
• The data of an object is referred to by many names.
• Attributes, properties, instance variables, …
• The behavior of an object is defined by its set of methods.
• Objects inherently know what type they are.
• Use data to keep track of its state
• Use methods to function properly
Prof. Chun-Han Lin, CSIE, NTNU
47
 Object Responsibilities

• In OOAD, it is best to view an object as something with

responsibilities.
• As you analyze (what’s the problem?), you discover
responsibilities that a system must fulfill.
• You will eventually find homes for the responsibilities in
objects designed.
• The process help you discover objects required.
• The problem domain also provide candidate objects.
• This is an example of moving from a conceptual
perspective to specification and implementation ones.
• Our book delves further into these three types of
perspectives.

Prof. Chun-Han Lin, CSIE, NTNU

48
 Review 6

• OO Paradigm

• Object Responsibilities

Prof. Chun-Han Lin, CSIE, NTNU

49
Object-Oriented Analysis and Design
01.Object-Oriented Paradigm.7

Chun-Han Lin (林均翰)

CSIE, NTNU
 Key Points 7

• Objects

• Objects are Instances of a Class

• Classes

Prof. Chun-Han Lin, CSIE, NTNU

51
 Objects

• Conceptual: a set of responsibilities

• Specification: a set of methods
• Implementation: a set of code and data
• Unfortunately, OOAD is often taught only at the
implementation level.
• If you have used OO programming languages
without doing analysis and design up front, then
you operated only at the implementation level.
• As you will see, there are great benefits from
starting with other levels first.

Prof. Chun-Han Lin, CSIE, NTNU

52
 Objects are Instances of a Class

• If you have two Student objects, each has its own data.
• Student A has different values for its attributes than
Student B.
• But they have the same methods.
• Because methods are associated with the class that acts
as a blueprint for creating new objects
• Objects are instances of a class.
• Classes define complete behavior of their objects.
• What data and methods they have, and how the
features are accessed ,whether they are public or
private

Prof. Chun-Han Lin, CSIE, NTNU

53
 Classes (1/5)

• The most important thing in a class is that it defines a type

with a legal set of values.
• Consider the following four types
• Complex numbers → real numbers → integers →
natural numbers
• Complex numbers is a class that includes all numbers;
real numbers is a subtype of complex numbers; integers
is a subtype of reals, …
• In each case, moving to a subtype reduces the set of
legal values.
• The same thing is true for classes.
• A class defines a type, and a subclass can be defined
that excludes some values from the superclass.
Prof. Chun-Han Lin, CSIE, NTNU
54
 Classes (2/5)

• Classes can exhibit inheritance relationships.

• Behaviors and data associated with a superclass are
passed down to the subclasses.
• A subclass can add new behaviors and data specific to it;
it can also alter inherited behaviors to handle its
specific situation.
• It is extremely desirable that any property true in a
superclass is true in the subclasses.
• The reverse is not true: it is okay for properties true in a
subclass not to be true in the superclass.
• E.g., property isPositive() is true in all natural numbers
but is certainly not true in all integers.
Prof. Chun-Han Lin, CSIE, NTNU
55
 Classes (3/5)

• Inheritance relationships are known as “is-a”.

• Undergraduate is-a Student.
• The phrase reinforces a concept that a subclass
represents a more refined and specific version of its
superclass.
• If need be, we can treat a subclass as its superclass.
• It has the same data and methods as its superclass.
• So, the code built to process its superclass can
equally apply to it.

Prof. Chun-Han Lin, CSIE, NTNU

56
 Classes (4/5)

• Classes can control the accessibility of the features.

• They can specify whether an data or method has an
accessibility of public, protected, or private.

• The ability to hide features of a class is encapsulation

or information hiding.
• However, encapsulation is broader than just data
hiding, as we will discuss later in the semester.

Prof. Chun-Han Lin, CSIE, NTNU

57
 Classes (5/5)

• Classes can control how their objects are created and

destroyed.
• OO programming languages (typically) provide special
methods as constructors and destructors (a.k.a.
finalizers) to handle the two phases in an object’s life
cycle.
• Constructors ensures that a new object is properly
initialized before any other object uses it.
• Destructors ensures that an object released all resources.
• Destructors can be tricky; in languages with garbage
collection, an inactive object might exist for a long time
before the garbage collector reclaims it.
Prof. Chun-Han Lin, CSIE, NTNU
58
 Review 7

• Objects

• Objects are Instances of a Class

• Classes

Prof. Chun-Han Lin, CSIE, NTNU

59
Object-Oriented Analysis and Design
01.Object-Oriented Paradigm.8

Chun-Han Lin (林均翰)

CSIE, NTNU
 Key Points 8

• Accessibility

• One Benefit of Superclasses

Prof. Chun-Han Lin, CSIE, NTNU

61
 Accessibility (1/2)

• Assume that …
• Object A is an instance of class X.
• Object B is an instance of class Y which is a subclass of X.
• Object C is an instance of class Z which is unrelated to X
and Y.
• UML model

Prof. Chun-Han Lin, CSIE, NTNU

62
 Accessibility (2/2)

• A public feature of class X means that A, B, and C can

access that feature.
• A protected feature of class X means that A and B can
access the feature but C cannot.
• A private feature of class X means that only A can access
the feature.
• Note that these are general definitions.
• Different programming languages may implement the
accessibility keywords in different ways.
• Consult specifications to your favorite OO
programming language

Prof. Chun-Han Lin, CSIE, NTNU

63
 Example Code of Accessibility

• Simple Java program

• Classes X, Y, and Z split between two packages foo
and bar.
• Test program instantiates A, B, and C, and then has
them call each other in various ways.
• Note that I split X and Y into two packages because the
protected keyword only follows the general definition
when classes are in different packages.
• In Java, the protected modifier acts like public for
classes in the same package!
Prof. Chun-Han Lin, CSIE, NTNU
64
 One Benefit of Superclasses

• Treat all instances in a superclass-subclass hierarchy as if

they were all instances of the superclass even some are
instances of subclasses
• Suppose 3 classes, Undergraduate, MastersStudent, and
PhDStudent in a software system
• Problem: we have to handle all instances of the 3 classes
at once, e.g., storing them in a collection by last name,
and displaying a roster of an entire university.
• Solution: make all 3 classes be a subclass of a class
Student; you can then add all students to a single
collection and treat them all the same.
Prof. Chun-Han Lin, CSIE, NTNU
65
 UML Model

Prof. Chun-Han Lin, CSIE, NTNU

66
 Review 8

• Accessibility

• One Benefit of Superclasses

Prof. Chun-Han Lin, CSIE, NTNU

67
Object-Oriented Analysis and Design
01.Object-Oriented Paradigm.9

Chun-Han Lin (林均翰)

CSIE, NTNU
 Key Points 9

• Another Benefit of Superclasses

• True Power: Clean Code!

• Polymorphism

• Abstract Class

• Summary

Prof. Chun-Han Lin, CSIE, NTNU

69
 Another Benefit of Superclasses

• Not only can you group all instances in a hierarchy

into a collection, but you can apply the same
operations to them as well.
• In the example, any method defined in the superclass,
Student, can be applied to all instances in the collection,
the List of Students.
• On the following slide, Student has a method called
saySomething() overridden by each subclass to say
something different.
• Yet look how clean the code is.

Prof. Chun-Han Lin, CSIE, NTNU

70
Prof. Chun-Han Lin, CSIE, NTNU
71
 True Power: Clean Code!
• The most powerful code in the previous example was …
for (Student s: students) {
System.out.println("" + s);
}
• Why?
• You can add as many subclasses to the Student hierarchy as you
want, and the code never has to change!
• It doesn’t even have to be recompiled!
• Indeed, given the right techniques, a server running the code
doesn’t even need to be brought down; a new subclass can be
dynamically loaded, and the code will recognize instances of the
subclass and do the right thing.
• Not just Java
• The benefits of polymorphism can be realized in any OO
programming language.

Prof. Chun-Han Lin, CSIE, NTNU

72
 Polymorphism (1/2)

• The previous example demonstrates polymorphism.

• Literally means many forms
• In OOAD, it means that we can treat objects as if they
were instances of an abstract class, but get the
behavior required for their specific subclass.
• The “many forms” refers to the many different
behaviors as we operate on a collection of objects
that are instances of subclasses of an abstract class.
• We will see many examples of polymorphism in the
semester, and you will get a chance to try it yourself in
homework.
Prof. Chun-Han Lin, CSIE, NTNU
73
 Polymorphism (2/2)

• In the book, polymorphism is defined as …

• Being able to refer to different derivations of a class
in the same way, but getting the behavior
appropriate to the derived class being referred to.
• As you can see, defining it is not easy! But, it is very
powerful, and the clean code example show why
designers should strive to design OO hierarchies that
allow them to write polymorphic code.
• There are other variations on polymorphism to
learn, we will get to those in future lectures.

Prof. Chun-Han Lin, CSIE, NTNU

74
 Abstract Class

• A class at the top of an object hierarchy is typically an

abstract one while a class near the bottom is a concrete one.
• An abstract class defines a set of generic behaviors for
related subclasses.
• Act as a placeholder for others by defining method
signatures that they must implement, by defining
method bodies that should be the same, and by defining
data that will be useful.
• In OO programming languages, an abstract class
cannot be instantiated.
• Instead you instantiate concrete classes, but access them
via the interface defined by an abstract class.
Prof. Chun-Han Lin, CSIE, NTNU
75
 Summary

• In the lecture, we touched on some OO concepts.

• Functional decomposition vs OO paradigm

• Requirements and change in software development
• Objects and classes
• Abstract and concrete classes
• Polymorphism
• Encapsulation

Prof. Chun-Han Lin, CSIE, NTNU

76
 Review 9

• Another Benefit of Superclasses

• True Power: Clean Code!

• Polymorphism

• Abstract Class

• Summary

Prof. Chun-Han Lin, CSIE, NTNU

77