Transcript General OO Concepts

General OO Concepts and
Principles
Three General OO Concepts
• Encapsulation
• Inheritance
• Subtype Polymorphism
Encapsulation
• First clearly stated by David Parnas ( “On the criteria to be used
in decomposing systems into modules”, CACM, 15, 9,
December 1972, 1053-1058), encapsulation is a mechanism for
improving the flexibility and comprehensibility of a system
while allowing the shortening of its development time.
• Parnas took the position that it was almost always incorrect to
begin the decomposition of a system into its elements based on
the algorithm to be implemented.
• Instead the elements should hide each difficult design decision
from the others. The resulting elements will not typically
correspond to steps in the processing.
• Christopher Alexander explored this in his thesis, published as
Notes on the Synthesis of Form, Harvard University Press, 1964.
Inheritance
• The relationship between classes whereby one class inherits
all or part of the description of another, more general, class,
and class instances inherit all the properties and methods of
the classes they belong to (Graham, 2001).
• Note that this differs from the concept of inheritance used in
biology or law. It also implicitly assumes objects cannot
change their class.
• I believe inheritance relationships should be determined
during preliminary design and validated during detailed
design, as they are primarily mechanisms for maximizing
code reuse.
Subtype Polymorphism
• The ability of an object or operator to refer to
instances of different classes at run time.
• In Java, subtype polymorphism is implemented by
use of abstract classes and interfaces.
• Note that polymorphism is not simply an aspect of
inheritance, but more importantly plays a role in
managing the complexity of object behaviour.
• The refactoring lecture (next) shows some elegant
ways to use subtype polymorphism effectively.
What to Do When Software
Smells…
• Robert C Martin collects principles of OOD, this
part of the lecture will discuss a few from his
collection.
• Resources
– <http://www.objectmentor.com/resources/articles/srp>
– <http://www.objectmentor.com/resources/articles/Principl
es_and_Patterns.PDF>
– Martin, R C, 2003, Agile Software Development,
Prentice-Hall.
• You apply these principles when software “smells.”
How Software May “Smell”:
• The system is rigid—hard to change because
everything has to change at once.
• The system is fragile—changes cause the system
to break in the strangest of places.
• The system is immobile—that is, not reusable.
• The system is viscous—doing things right is hard.
• The system is needlessly complex.
• The system contains needless repetition.
• The system is opaque—hard to understand.
Have you ever seen software with these problems?
Some of Martin’s Principles of
Object-Oriented Design
• The Open-Closed Principle - OCP - A class should be
extensible without requiring modification
• The Liskov Substitution Principle - LSP - Derived classes
should be substitutable for their base classes
• The Dependency Inversion Principle - DIP - Depend upon
abstractions. Do not depend upon concretions
• The Interface Segregation Principle - ISP - Many client
specific interfaces are better than one general purpose
interface.
• The Single-Responsibility Principle - SRP - A class should
have only one reason to change.
Open-Closed Principle (OCP)
•
•
•
•
A module (class) should be open for extension but closed
for modification (originally by Bertrand Meyer).
Classes should be written so that they can be extended
without requiring modification.
This allows one to change what a class does without
changing the class’s source code.
To extend the behaviour of a system (in response to a
requested change) add new code, don’t modify existing
code.
Abstraction (and subtype polymorphism) are the keys to
the Open Closed Principle.
Liskov Substitution Principle
(LSP)
•
•
•
•
Subclasses should be substitutable for their base classes.
(originally by Barbara Liskov)
A user of a base class instance should still function if given
an instance of a derived class instead.
“A derived class should have some kind of specialized
behavior (it should provide the same services as the
superclass, only some, at least, are provided differently.)”
The contract of the base class must be honored by the
derived class. (See Design by Contract)
If this principle is violated, then it will cause the OpenClosed Principle to be violated also. Why?
Dependency Inversion Principle
(DIP)
Depend upon abstractions. Do not depend upon concrete
implementations (originally defined by Martin).
• High level classes should not depend on low level classes.
• Abstractions should not depend upon the details.
• If the high level abstractions depend on the low level implementation details,
then the dependency is inverted from what it should be.
• High level classes should contain the “business logic”, low level classes
should contain the details of the (current) implementation.
• Access instances using interfaces or abstract classes to avoid dependency
inversion.
If higher levels of the application are not going to depend on
particular, low level implementations, how does one construct
the necessary low level implementations?
Interface Segregation Principle
(ISP)
•
•
•
•
•
Many client-specific interfaces are better than one general purpose
interface. (Martin)
If you have a class with several different uses, create separate (narrow)
interfaces for each use.
The alternative is that all uses share the same, large interface (and most
uses will need only a small number of the methods.)
Instead the uses of the class can be organized as groups of related
methods, each of which serves a different purpose. Each of these
groups becomes a separate interface.
The purpose is to make clients use as small and as coherent an
interface as possible.
Fat interfaces lead to inadvertent couplings and accidental
dependencies between classes.
Single-Responsibility Principle
(SRP)
•
•
•
•
•
A class should have only one reason to change
(originally by Martin).
A responsibility is “a reason for change.”
The responsibilities of a class are axes of change.
If it has two responsibilities, they are coupled in
the design, and so have to change together.
Simple, yet hard to get right.
Hint: delegate!
Sometimes refered to as “modularity” (e.g. in
expression “breaking the modularity”)
Summary
• Understand why encapsulation, inheritance, and
polymorphism are basic concepts of object
orientation.
• Know the OCP, LSP, DIP, ISP, and SRP and why
they promote good object-oriented design. Robert
Martin actually has identified close to a dozen
principles that we’ll discuss from time to time. See
http://www.objectmentor.com/resources/articles/srp and
http://www.objectmentor.com/resources/articles/Principles_and_Patterns.PDF