Evaluating an Object-Oriented Design ©SoftMoore ConsultingSlide 1

Issues in the Development of Object-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.) ©SoftMoore ConsultingSlide 2

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++) ©SoftMoore ConsultingSlide 3

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 ©SoftMoore ConsultingSlide 4

Types of Class Coupling Interface Coupling Concrete Class Coupling Inheritance Coupling Internal Representation Coupling ©SoftMoore ConsultingSlide 5

Interface Coupling Class references only the public operations of an abstract class or interface Weakest form of coupling Usually very desirable ©SoftMoore ConsultingSlide 6

Concrete Class Coupling Class references the public operations of a concrete class Generally acceptable form of coupling Most common type of coupling ©SoftMoore ConsultingSlide 7

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 ©SoftMoore ConsultingSlide 8

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). ©SoftMoore ConsultingSlide 9

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) ©SoftMoore ConsultingSlide 10

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()... } } ©SoftMoore ConsultingSlide 11 CYX X myYmyX

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 ©SoftMoore ConsultingSlide 12

Rumbaugh on the Law of Demeter ©SoftMoore ConsultingSlide 13 “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 ©SoftMoore ConsultingSlide 14

Types of Class Cohesion Single Abstraction Cohesion Sequential Cohesion Logical Cohesion Temporal Cohesion ©SoftMoore ConsultingSlide 15

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 ©SoftMoore ConsultingSlide 16

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 ©SoftMoore ConsultingSlide 17 “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.) ©SoftMoore ConsultingSlide 18 A class consisting only of class scoped (static) attributes and operations is often referred to as 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 ©SoftMoore ConsultingSlide 19

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. ©SoftMoore ConsultingSlide 20 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 ©SoftMoore ConsultingSlide 21 ClientServer ClientAbstractServer 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. ©SoftMoore ConsultingSlide 22

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 ©SoftMoore ConsultingSlide 23 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). ©SoftMoore ConsultingSlide 24

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 ©SoftMoore ConsultingSlide 25 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) ©SoftMoore ConsultingSlide 26

Example: Copy Program Redesign Redesign so that Copy is dependent on abstractions and the lower level classes are dependent on the same abstractions. ©SoftMoore ConsultingSlide 27 Copy WriterReader KeyboardPrinter

Design by Contract: Achieving the Liskov Substitution 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. ©SoftMoore ConsultingSlide 28

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 ConsultingSlide 29

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.) ©SoftMoore ConsultingSlide 30

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. ©SoftMoore ConsultingSlide 31