General OO Concepts and Principles CSE301 University of Sunderland Harry R. Erwin, PhD

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 the classes they belong to (Graham, 2001).

inherits

all or part of the description of another, more general, class, and class instances inherit all the properties and methods of • 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 (read!!!) – – – 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

in Lecture 2.) • If this principle is violated, then it will cause the Open Closed 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, delegate, delegate!

What Should You do When Software

Doesn’t

Smell?

• Nothing!

• But keep the design as good as it can be.

• This is like sterile procedure in surgery. It makes surgery

possible.

• Don’t tolerate any signs of rot.

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. Bob 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