Evaluating an Object-Oriented Design ©SoftMoore ConsultingSlide 1.

Evaluating an Object-Oriented Design

©SoftMoore Consulting Slide 1

Issues in the Development ofObject-Oriented Software

• Encapsulation of design decisions

• Class coupling and cohesion

• Using inheritance and polymorphism effectively

• Object-oriented metrics

• Reuse

• Programming styles and standards

• Management Issues (staffing, training, etc.)


Class Coupling

• The coupling between two classes is a measure of how much they depend on each other (degree of dependence)

• Addresses two related issues– How much do I need to understand about related classes in

order to understand a particular class?– If changes are made in one class, what is the potential impact

with respect to other classes in the system?

• Coupling can range from none (independent classes) to very strong (e.g., friend classes in C++)


Class Coupling(continued)

• Dependency between classes can be in one direction (class A depends on class B, but not conversely) or both directions

• Dependency may be logical (class/package structure) or physical (file/directory structure)

• Direct correlation between low coupling and reusability

• General goal: minimize the amount of coupling between classes


Types of Class Coupling

• Interface Coupling

• Concrete Class Coupling

• Inheritance Coupling

• Internal Representation Coupling


Interface Coupling

• Class references only the public operations of an abstract class or interface

• Weakest form of coupling

• Usually very desirable


Concrete Class Coupling

• Class references the public operations of a concrete class

• Generally acceptable form of coupling

• Most common type of coupling


Inheritance Coupling

• Class is defined as a subclass of another class

• Strong coupling but often acceptable (factor out commonality and promote polymorphism/reuse)

Note: Minimize coupling introduced by inheritance by not accessing inherited attributes directly– private attributes only– public or protected operations to access private attributes


Internal Representation Coupling

• Class has direct access to the private attributes of another class

• Examples– friend classes in C++– inner classes in Java

• Very strong coupling and usually undesirable

• Use for two highly interdependent classes that work closely together as a pair to achieve a common purpose (e.g., a container class and its associated iterator class).


The Law of Demeter(Lieberherr)

Inside a method m of class C, we should call only operations of the following classes (called preferred supplier classes):

• The class C itself

• The classes of any argument objects passed to m

• The classes of objects created locally within m

• The classes of objects declared within C(variables representing attributes and associations)


Example: Violation of the Law of Demeter

public class X { void doSomething() { ...} }

public class Y { X myX; public X foo() { ... return myX; } }

public class C { Y myY; void m() { ... myY.foo().doSomething() ... } }


C Y X

X

myY myX

Comments on The Law of Demeter

• The Law of Demeter essentially says that you should talk only to– yourself (current class)– to close relatives (classes of attributes and classes of local

objects)– and to friends who visit you explicitly (argument classes)

• Goal is to reduce coupling between classes

• Performance tradeoffs analogous to normalization


Rumbaugh on the Law of Demeter


“A method must be able to traverse links to obtain its neighbors and must be able to call operations on them, but it should not traverse a second link from the neighbor to a third class.”

– James Rumbaugh

Class Cohesion

• Cohesion is a measure of strength of connectivity of the items within a class (binding strength).– Coupling describes the relationships between classes.– Cohesion describes the relationships within a class.

• Addresses the purpose of the class: Do the members (attributes, operations, etc.) of a class work together toward a single, common purpose?

• Highly cohesive classes are usually more easily understood and less susceptible to change (more stable).

• General goal: strong class cohesion


Types of Class Cohesion

• Single Abstraction Cohesion

• Sequential Cohesion

• Logical Cohesion

• Temporal Cohesion


Single Abstraction Cohesion

• The class encapsulates a single abstraction(strong cohesion)

• All items work together to achieve a common purpose

• Usually provides operations in the public interface that manipulate “hidden” representation details


• The items within the class must be accessed or activated in a particular order

• May be required at some level of abstraction within the system but sequential nature should be hidden as much as possible

• Limit coupling to a class with sequential cohesion

Sequential Cohesion


“A system decomposition based on the order in which operations are to be executed stands to suffer considerably from any change of external specifications.”

– Bertrand Meyer

Logical Cohesion

• There is a weak, logical connection among the items in the class but not in terms of attributes, operations, or control

• Example: Class of mathematical functions (sine, cosine, etc.)


A class consisting only of class scoped (static)attributes and operations is often referred toas a class utility.

Temporal Cohesion

• Items are bound together within a class because they must be used at approximately the same time

• Example: system initialization class

• Weak form of cohesion that should generally be avoided

• Sometimes necessary in multi-tasking systems to reduce the number of tasks


The Open-Closed Principle(Bertrand Meyer)

• “Open for extension” means that the behavior can be extended.

• “Closed for modification” means that changes to the source code are not allowed.


Software components should be open for extension but closed for modification.

Designing for the Open-Closed Principle

• Sample design that does not conform to the open-closed principle (Client is not closed)

• Redesign for conformance to the open-closed principle


Client Server

Client AbstractServer

Server

Implications of the Open-Closed Principle

• Exploit virtual functions and abstract classes

• Make instance variables (data members) private

• Minimize the use of global variables.

• Minimize the use of run-time type identification that processes similar objects using a multi-way branch based on an object's class.


The Liskov Substitution Principle(Barbara Liskov)

• Goal: “Plug compatible” components that can be freely substituted in a given context

• Implication: All subclasses of a common superclass will share its public interface.– can add new operations– can override existing (virtual) operations– can not hide existing operations


An instance of a subclass must be substitutable and usable wherever a variable of one of its ancestor classes is allowed.

The Liskov Substitution Principle(continued)

• Question: Should class Square be a subclass of class Rectangle?

• Discussion– Is Rectangle mutable? Consider operations such as setWidth

and setHeight.– Consider identity in mathematics (identity by value) versus

identity in class design and inheritance (identity by reference).


Example: Copy Program(Robert Martin)

• Consider a simple copy program that is charged with the task of copying characters typed on a keyboard to a printer. Assume that the implementation platform does not have an operating system that supports device independence.

• Initial design


Copy

PrinterKeyboard

Comments on the Initial Design

• Classes Keyboard and Printer are reusable, but ...

• What if we wanted to copy from the keyboard to a disk file?

• Class copy is not reusable– copy is dependent on its details– does not conform to the open-closed principle

(can’t be extended without modification)


Example: Copy Program Redesign

Redesign so that Copy is dependent on abstractions and the lower level classes are dependent on the same abstractions.


Copy

WriterReader

Keyboard Printer

Design by Contract: Achieving the LiskovSubstitution Principle (Bertrand Meyer)

Two major considerations:

• Operations should declare– preconditions: properties that must be true whenever the

operation is invoked– postconditions: properties that the operation guarantees upon its

completion

• When overriding an operation in a subclass, its precondition can be replaced only by a weaker one and its postcondition can be replaced only by a stronger one.


Responsibilities Under Design by Contract

• Client is responsible for ensuring the precondition before invoking the operation

• Operation/method is responsible for ensuring the postcondition upon return (assuming that its preconditions are satisfied)


©SoftMoore Consulting

Summary of Some Basic Design Principles

• Software components should be open for extension but closed for modification. (Open-Closed Principle)

• An instance of a subclass must be substitutable and usable wherever a variable of one of its ancestor classes is allowed. (Liskov Substitution Principle)

• A class should not traverse a link from the neighbor to a third class. (Law of Demeter)

• Favor object composition over class inheritance.Reuse behavior by moving it into objects that can be composed together. (We don’t always need to use subclassing to achieve polymorphic behavior.)

Slide 30

©SoftMoore Consulting

Summary of Some Basic Design Principles(continued)

• Encapsulate properties that are likely to change.

• Program to an interface, not an implementation.– Inherit only from abstract classes.

• Strive for loose coupling between objects that interact.

Slide 31

Evaluating an Object-Oriented Design ©SoftMoore ConsultingSlide 1.

Documents

Transcript of Evaluating an Object-Oriented Design ©SoftMoore ConsultingSlide 1.