Page 164 - DCAP308_OBJECT_ORIENTED_ANALYSIS_AND_DESIGN

Object Oriented Analysis and Design

Notes 2. Inheritance coupling: Inheritance coupling is a form of coupling between super and sub
classes. A subclass is coupled to its superclass in terms of attributes and methods. We need
high inheritance coupling. For this each specialisation class should not inherit lot of
unrelated and unneeded methods and attributes.

!

Caution If the superclass is overwriting most of the methods or not using them, then it is
an indication that the inheritance coupling is low.

Corollary 2: Single Purpose

Before studying corollary 2, we will discuss cohesion.
The interaction within a single object or software component is called cohesion. Cohesion
reflects the “single-purposeness” of an object. Highly cohesive components can lower coupling
because only a minimum of essential information need be passed between components. Method
cohesion means that a method should carry one function.
A method that carries multiple functions is undesirable.

Did u know? Class cohesion means that all the class’s methods and attributes must be
highly cohesive, meaning to be used by internal methods or derived classes’ methods.

Now we will discuss corollary 2 as follows:
Every class should be clearly defined and necessary in the context of achieving the system’s
goals.

When we document a class, we should be able to explain its purpose in a sentence or two.
If we cannot, then the class should be subdivided into independent pieces.
Each method must provide only one service.

Each method should be of moderate size, no more than a page; half a page is better.
Corollary 3: Large Number of Simpler Classes

There are benefits in having a large number of simpler classes because the chances of
reusing smaller classes in other projects are high.
Large and complex classes are too specialised to be reused.

Object-oriented design offers a path for producing libraries of reusable parts.
Reusability is not used because of the following reasons:
Software engineering textbooks teach new practitioners to build systems from “first
principles”; reusability is not promoted or even discussed.

The “not invented here” syndrome and the intellectual challenge of solving an interesting
software problem in one’s own unique way mitigates against reusing someone else’s
software component.
Unsuccessful experiences with software reusability in the past have convinced many
practitioners and development managers that the concept is not practical.

158 LOVELY PROFESSIONAL UNIVERSITY