1

CSC 422

Dr. Spiegel

EncapsulationConnascence (born together, dependence)Cohesion

2

Encapsulation: Review

Encapsulation separates the contractual interface of an abstraction from its implementation.

Levels of encapsulation:Level 0 - No encapsulationLevel 1 - Encapsulation within a procedureLevel 2 - Encapsulation within a classLevel 3 - Encapsulation within a packageLevel 4 - Encapsulation within a component

3

Class Interaction:Buttons and Lamps –

The Use Case and the ModelName: Turn lamp on and offActors: ButtonPusherType: PrimaryDescription: When the ButtonPusher presses the button, the

lamp goes on if it was off, and goes off if it wasalready on.

LampButton

Turn on() or Turn off()

4

Coding Directly from the Model

--------------lamp.h---------------- class Lamp {

public: void TurnOn(); void TurnOff();

}; -------------button.h--------------- class Button {

public: Button(Lamp& l) : itsLamp(&l) {} void Detect(); private: Lamp* itsLamp;

}; -------------button.cc-------------- #include “button.h” #include “lamp.h” void Button::Detect() { bool buttonOn = GetPhysicalState(); if (buttonOn) itsLamp->TurnOn(); else itsLamp->TurnOff(); }

Problems:

Any change to Lamp will require a corresponding change to (or at least a recompilation of) Button

It is very difficult to reuse either component alone, for example a button to start a motor and not to turn on a lamp

5

A better solution

Button{abstract}

ButtonImplementation Lamp

ButtonClient

{abstract}

6

Why is it better?

Underlying abstraction is to relay an on/off gesture from a user to a target object

Has removed implementation from the abstraction

Button knows nothing about implementation of detecting the user gesture

Button knows nothing about Lamp Highly resistant to change and high level

abstractions are easily reused elsewhere Use case requirements are still easily

traceable in the design

7

Code Solution

----buttonClient.h-----class ButtonClient {public:virtual void TurnOn() = 0;virtual void TurnOff()= 0;

};

-------button.h--------class ButtonClient; //external?class Button {public:Button(ButtonClient&);void Detect();virtual bool GetState() = 0;

private:ButtonClient* itsClient;

};

---------button.cc----------------#include button.h#include buttonClient.hButton::Button(ButtonClient& bc)

: itsClient(&bc) {}void Button::Detect() {bool buttonOn = GetState();if (buttonOn)itsClient->TurnOn();

elseitsClient->TurnOff();

}

-----------lamp.h----------------class Lamp : public ButtonClient {public:virtual void TurnOn();virtual void TurnOff();

};---------buttonImp.h-------------class ButtonImplementation : public Button {public:ButtonImplementaton(ButtonClient&);virtual bool GetState();

};

8

OO Key Design Ideas - The Open/Closed Principle

Classes should be open for extension, but closed for modification

A class is open for extension if we can add functionality to it: e.g. expand the set of operations or add fields to its data structures

A class is closed for modification if it is available for use by other classes: i.e. it has a stable and well-defined interface

This is normally implemented with inheritance/polymorphism in OO systems

Connascence

Definition two modules (classes, or methods) are so

intertwined that if you make a change to one it is likely that a change in the other will be required.

measure of how well encapsulation is applied within the system

10

Connascence

Connascence between two software elements A and B means either that you can postulate some change to A

that would require B to be changed (or at least carefully checked) in order to preserve overall correctness, or

that you can postulate some change that would require both A and B to be changed together in order to preserve overall correctness.

11

a generalization of the notions coupling and cohesion from structured design for more complex encapsulation structures.

Fan-out is the measure for the number of references to other procedures by lines of code within a given procedure.

Cohesion is a measure of the “single-mindedness” of the lines of code within a given procedure in meeting the purpose of that procedure.

Coupling is a measure of the number and strength of connections between procedures.

Connascence

Types of Connascence

13

Types of Connascence (con’t)

Static connascence – can be determined from the code/structure of the classes

connascence of name - int i; i := 7 connascence of type or class - both i’s should have the

same type connascence of convention – for example, different ranges

of account numbers have different meanings connascence of algorithm - two elements that share the

same algorithm connascence of position

sequential – have to appear in the right order adjacent – have to be next to each other for example, actual parameters should have the same order

as the formal parameters

14

Dynamic connascence - based on the execution pattern of the running code, i.e. more on the objects than on the classes

connascence of execution – for example, initialization of a variable before use

connascence of timing – for example, an instruction to stop a röntgen machine has to be given within 50 ms after the instruction to start it

connascence of value – for example, a arithmetical constraint: the 3 angles of a triangle are 180 degrees together

connascence of identity – for example, 2 objects (O1 and O2) that refer both to an other object, always have to refer to the same object O3

contranescence - connascence of difference – for example, if a class C inherits from class A and B, then the methods of A and B should not have the same names

Types of Connascence (con’t)

15

Connascence and Encapsulation

Encapsulation can be used to manage connascence

Directives: Minimize overall connascence by breaking the

system into encapsulated components Minimize any remaining connascence that crosses

encapsulation boundaries Maximize the connascence within encapsulation

boundaries

16

Connascence abuses in OO systems

The friend function of C++ gives an other class access to the private/implementation

aspects of a class - thus large connascence beyond encapsulation boundaries

Unconstrained inheritance Gives subclasses access to the private/implementation

aspects of the superclass (Separate inheritance of abstract behavior from inheritance

of the internal implementation of that behavior!) Relying on accidents of implementation

Use of accidents of the implementation causes connascence of algorithm – for example, a class SET in which items are taken from the set in the same order as in which they where added to the set

17

Domains, Encumbrance, Cohesion, & Coupling

Domains: regions where classes play a role

Encumbrance: burden, impediment, complexity of a class

Cohesion: coherence of a class Coupling: Level of interdependence

between entities

18

Class Cohesion Measures the interrelatedness of the features in the

external interface of a class How good is the cohesion of a class as an

implementation of an abstraction Low cohesion - bad! high cohesion - good! No quantitative measure Some people say: the higher the overlap in use of

private variables by methods, the higher the cohesion, but

Cohesion has to be visible from outside Private/implementation variables can change without

influencing the interface, so the measure is instable

19

Symptoms of low class cohesion

Mixed Instance Cohesion - the class has some features that are undefined for some objects of the class

Example: class Salesperson has an attribute commission-rate, but a Salesperson works either commission-based or not. In the second case commission-rate is irrelevant

Solution for Mixed Instance Cohesion is normally to split the class into subclasses

Salesperson splits into Commissioned_Salesperson and NonCommissioned_Salesperson

20

Mixed Domain Cohesion - where the class contains features that are not relevant for the domain of the class

Here domain is: Application domain - contains classes important for an

application Business domain - contains classes important for an industry

or company Architecture domain - contains classes important for an

implementation architecture Foundation domain - contains classes important for all kinds

of companies and architectures Semantic subdomain - DATE, TIME, MONEY Structural subdomain - QUEUE, SET, LIST Fundamental subdomain - INTEGER, BOOLEAN

Symptoms of low class cohesion

21

Mixed Domain Cohesion

Example - Class REAL contains the method arctan

But arctan is not really an aspect of a REAL number, it is an aspect of a class ANGLE.

For example, does a class REAL need a method convert-temp, since this method converts a real number into an other real number?

Features have to be essential for a class. Ask if the class can be built without the class of

the other feature – for example, can REAL be built without ANGLE? ANGLE without REAL?

22

Mixed Role Cohesion - the class has a feature from the same domain, but is not part of the abstraction

Example: class PERSON has a method number_of_dogs_owned

But Dogs are not really part of the abstraction person, they are not an essential part

Do we have to add methods for cats, horses, parakeets, goldfishes, etc.?

Mixed Role Cohesion reduces the reusability of a class

Symptoms of Mixed Domain Cohesion

Class Cohesion

Method Cohesion

25

Encumbrance of a class

Quantitative measure for the complexity of a class. The direct class-reference set of a class C consists

of those classes to which C refers directly, i.e. classes D such that:

C inherits from D C has an attribute of class D C has an operation with an input argument of class D C has a variable of class D C has a method that sends a message with a return

argument of class D C supplies D as an actual class parameter to a

parameterized class C has a friend class D (in C++)

26

Let the direct class-reference set of C comprise the classes C1, C2, ..., Cn.

Then the indirect class-reference set of C is the union of the direct class-reference set of C and the indirect class-reference sets of C1, C2, ..., Cn.

The direct encumbrance of a class is the size of its direct class-reference set. The indirect encumbrance of a class is the size of its indirect class-reference set.

Encumbrance of a class

27

The class Rectangle and its indirect class-reference set with each class’s indirect encumbrance marked.

Rectangle4

Boolean0

Real0

Length2

Point3

Coupling

What is Coupling?

how interdependent or interrelated modules(classes, objects, methods) are in a system

when one class depends on another we say they are coupled

Types of Coupling

Inheritance Coupling how tightly coupled the classes are in an

inheritance hierarchy

Interaction Coupling coupling among methods and objects

through message passing

Interaction Coupling

31

Cohesion vs. Coupling

Goal: High Cohesion Low Coupling

Functions handle a single task completely, while depending on others as little as possible

32

Law of Demeter

Messages should be sent only by an object

to itself

to an object contained in an attribute of itself or a superclass

to an object that is passed as a parameter to the method

to an object that is created by the method

to an object that is stored in a global variable

33

Law of Demeter

Guideline to limit the direct encumbrance of a class (Lieberherr and Holland):

For an object obj of class C and for any operation op defined for obj each target object of a message within the implementation of op must be one of the following objects:

The object obj itself An object referred to by an argument within op’s

signature An object referred to by a variable of obj An object created by op An object referred to by a global variable

34

Subclasses and Subtypes

For class S to be a true subtype of class T, then S must conform to T

A class S conforms to class T, if an object of class S can be provided in any context where an object of class T is expected and correctness is still preserved when any accessor method is executed

Known as the Liskov Substitutability Principle But we can have subclasses which are not

subtypes.

35

Subclasses and Subtypes (2)

In a sound OO system, all subclasses should also be subtypes, e.g. digit is a specific int subtype

This is not always possible

Ellipse

Circle

But what happens when a circle gets a stretch_along_x_axismessage?

Ellipse Circle

ConicSection

36

Inheritance Pitfalls

Mistaken Aggregates - using inheritance where the relationship is actually aggregation

Aeroplane

Wing EngineFuselageTail

37

Abusing Multiple Inheritance

Aeroplane

Wing EngineFuselageTail

38

Inverted Hierarchy

Board Member

Manager

Employee

Employee

Manager

Boardmember

39

Some design problems

Roles versus Inheritance Example

Computer Science Conference wants a registration system

Conference members can be: Organisers Special Guests Tutorial Presenters Paper Presenters Industrial Registrants Academic Registrants Student Registrants

40

A simple solutionConferenceMember

PaperPresenter

TutorialPresenter

SpecialGuest

Organiser

Industrial Academic Student

Registrant

41

Some problems with the solution

What happens if we have an organiser who is also giving a tutorial?

What happens if a student registrant is also giving a paper?

What happens if a conference member withdraws their paper but still attends as an academic registrant?

42

A partial solution - multiple inheritance

ConferenceMember

PaperPresenter

TutorialPresenter

SpecialGuest

Organiser

Industrial Academic Student

Registrant

StudentPaperPresenter

OrganiserTutorialPresenter

43

Another solution

In this particular case, multiple inheritance is not a particularly good solution

Roles are a much better solution as they are more flexible

ConferenceMember

ConferenceRole

performs 1..*

AcademicIndustrial

PaperPresenter

TutorialPresenterRegistrant

SpecialGuest

Organiser

Student