Cohesion

• The degree of interaction within a module

• Seven categories or levels of cohesion (non-linear scale) – listed from
“low” (bad) to “high” (good)
• Coincidental – implements multiple and unrelated actions
• Logical – implements a set of related actions, one of which is
specified by the calling module
• Temporal – implements a set of actions related in time (i.e. need
to be performed in sequence)
• Procedural – implements a series of actions dictated by a product-
specific procedure
• Communicational – implements a series of actions dictated by a
product-specific procedure and all actions operate on the same
data
• Functional – implements exactly one action
• Informational – implements a number of actions, each with its
own entry point, with independent code for each action, all
performed on the same data structure
 Coupling
• The degree of interaction between two modules
• Five categories or levels of coupling (non-linear scale) – listed from
“high” or “tight” (bad) to “low” or “loose” (good)
• Content – one module directly references the physical contents of
another
• Common – modules share access to global data (data directly
accessible by any module)
• Control – one module passes a control value to another (quite
similar to logical cohesion)
• Stamp – one module passes a data structure to another module,
and the called module operates on a subset of the structure’s
components
• Data – one module passes a data structure to another module,
and the called module operates on all of the structure’s
components
Key Object-Oriented Definitions
 Information Hiding
• Data abstraction
• The designer thinks at the level of an ADT – focus is on
requirements (what needs to be done), not on implementation
(how something is done)
• Procedural abstraction
• Define a procedure (method) — “extend / specialize the
language”
• Both are instances of a more general design concept: information
hiding
• Design modules such that implementation details that can
potentially change are hidden from the invoking software
• Future changes / enhancements at the implementation level are
therefore localized within one module and should not affect other
modules
• Changes cannot affect invoking modules – they lack knowledge of
and/or access to implementation details of the changed method
 Relationships between object:
Composition vs. Aggregation vs. Association
• Association: a relationship between two or more objects
where all objects in the relationship have their own lifecycle
and there is no owner / master / controller. E.g. a Student
taught by a Teacher.
• Aggregation: a specialized form of Association where all
objects have their own lifecycle but there is “ownership”.
E.g. a Teacher is a member of a Department
• Composition: a specialized form of Aggregation wherein
child objects exist only within the life cycle of the parent
object. If the parent object is deleted, all its child objects will
also be deleted. E.g. a Room within a Building
 Object-Oriented Paradigm
• Reasons why the structured paradigm was initially embraced
• The alternative was no paradigm at all – “better than
anarchy”
• Components of well designed OO software tend to be
testable, reusable, and efficiently maintainable and
extendable – much more so than non-OO software
• Reasons for the ongoing success of the object-oriented
paradigm
• See previous bullet
• The object-oriented paradigm gives overall equal attention
to data and operations
• At any one time, data or operations may be favored
• A well-designed object (high cohesion, low coupling) models
all the aspects of an entity (physical and/or procedural)
• Implementation details are hidden
 Perceived weaknesses of the
Object-Oriented Paradigm
• Development effort and size can be appear to be large in
contrast to non-OO
• Significantly more “boilerplate” code than non-OO languages – but
much of the “boilerplate” is now automatically provided by an IDE
• Object-oriented projects can be larger than expected, if coming
from a non-OO environment
• Even taking the learning curve into account
• Especially if there is a GUI
• Inheritance can cause problems
• The fragile base class problem (to reduce ripple effects, all classes
need to be carefully designed up front)
• The use of polymorphism and dynamic binding can potentially lead to
confusion depending on developer experiences and training
• It is easy to write bad object-oriented code
• But, it is easy to write bad code in any language, and much easier in a
non-OO language