Elements and Principles of

Object Orientation

Elements of OOAbstractionEncapsulationModularityHierarchy: Inheritance & Aggregation 4 major/essential elements 3 minor/helpful elements

TypingConcurrencyPersistence

collaboration

contract

AbstractionAn abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provides crisply defined conceptual boundaries, relative to the perspective of the user.

Focuses on outside view of an object:Behavior/implementation separation

Specifies responsibilities of objects of the same kind

Abstraction

characteristicsresponsibilities

Defines a contract on which other objects may dependAbstractio

ncharacteristicsresponsibilities

clientserver

Every object collaborates with other objects to achieve some behavior

Abstraction

perspective of the user

essential characteristics

kinds of objects

crisply defined conceptual boundaries

Encapsulation Encapsulation is the process of

compartmentalizing the elements of an abstraction that constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation.

Works hand-in-hand with abstraction:For abstraction to work, implementations must be encapsulated.Intelligent encapsulation localizes

design decisions that are likely to change.

Encapsulation

So its client doesn’t need to care about its inner works.

A client will not notice it even if its Dog Taunter is replaced.

ModularityModularity is the property of a system

that has been decomposed into a set of cohesive and loosely coupled modules.

The essential method that we use to manage complexity is “divide and conquer”

The OOA process leads to a set of abstractions used in the domain.

The OOD process leads to a set of program modules that can be compiled separately, but which have connections with other modules.

Modules: - Conceptual breakdown of a system: subsystems, components, objects- Physical containers of program: packages, classes, etc

Objects are too tiny and can

hardly be used alone

Objects within the same

component are closely related

Objects within the same

component are loosely related

Modularity

Modularity – a real world example

+ ++

Highly cohesive components

Loosely coupled components

Cohesion & Coupling

Hierarchy Hierarchy is a ranking or ordering of abstractions.

The two most important hierarchies in a complex system areits class structure (the “is-a” hierarchy)andIts object structure (the “part-of” hierarchy)

Class structure (generalization/specialization)

Object structure (aggregation/composition)

Generalization/Specialization

Aggregation/Composition

Typing Typing is the enforcement of the class of an

object, such that objects of different types may not be interchanged, or at the most, they may be interchanged only in very restricted ways.

An object-oriented language can be strongly typed, weakly typed, or even untyped.

An object-oriented language can support dynamic typing (or binding) or only static typing (or binding).

Benefits of strong typing:-Prevents programs from “crashing” mysteriously-Early error detection is extremely valuable-Helps to document programs-Helps compilers generating more efficient object code

Polymorphism, made possible by late binding, is the most powerful feature of OOP languages next to their support for abstraction; and is a central concept in OOD.

Typing

Concurrency Concurrency is the property that distinguishes an active object from one that is inactive.

Physical concurrency – using multiple CPUs . Vs. Illusionary concurrency – using a single CPU with time-slicing.

Heavyweight concurrency – using multiple processes. Vs. Lightweight concurrency – using multiple threads within a single O/S process.

Whereas OOP focuses on data abstraction, encapsulation, and inheritance, concurrency focuses on process abstraction and synchronization.

Each object (drawn from an abstraction of the real world) that represents a separate thread of control is called active.

Concurrency

Persistence Persistence is the property of an object through which its existence transcends time (i.e., the object continues to exist after its creator ceases to exist) and/or space (i.e., the object’s location moves from the address space in which it is created).

Persistence

Principles of OODThe Single-Responsibility Principle (SRP)The Open-Closed Principle (OCP)The Liskov Substitution Principle (LSP)The Dependency-Inversion Principle (DIP)The Interface-Segregation Principle (ISP)

Design SmellsPoor design smells, like a plastic sack of 12-day

old kitchen garbageRigidity = Hard-to-change: changing one place cause

never-ending succession of changes.Fragility = A change to one part of the system causes

it to break in many other, completely unrelated, parts.Immobility = Hard to disentangle the system into

units (or components) that can be reused in other systems

Viscosity = The development environment is held together with duct tape and library paste. It takes forever to go around the edit-compile-test loop.

Design Smells (cont’d)Needless Complexity = There are a lot of very

clever code structures that are not actually necessary right now, but could be very useful one day.

Needless Repetition = The code looks like it was written by two programmers named Cut and Paste.

Opacity = Elucidation of the originator’s intent presents certain difficulties related to convolution of expression.

Mismanaged dependencies

Spaghetti code

The Single Responsibility PrincipleSRP = A class should have only one reason

to change.

Violation of SRP

Not cohesive

Use cohesive classes, each

focuses on a single topic

The Open-Closed PrincipleOCP = Software entities (classes, modules,

functions, etc) should be open for extension, but closed for modification.

The Liskov Substitution PrincipleLSP = subtypes must be substitutable for

their base types.

The Dependency Inversion PrincipleDIP =

High-level modules should not depend upon low-level modules. Both should depend upon abstractions.

Abstractions should not depend upon details. Details should depend upon abstractions.

The Interface Segregation PrincipleISP = client should not depend upon

methods that they do not use.