elements of oo abstraction encapsulation modularity hierarchy: inheritance & aggregation 4...
TRANSCRIPT
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.