Encapsulation CodeCampIasi 16 oct 2010

Encapsulationthe good, the bad, the ugly
EigelSilviu-Horea, silviu.eigel@endava.com
www.endava.com
16 Octombrie2010

Agenda
From functional decomposition to OOP
Encapsulation
From bad and ugly to “The Good”
Building up encapsulation
Handling variation
Conclusions

Some values
Cohesion
How closely the operations in a module are related
Coupling
The strength of a
connection between
two modules

Some problems
Requirements Always Change
Change is necessary
New variation to an existing theme

Back in the days
Professor and students
Functional decomposition
Lasagna

OOP
Objects as data with methods
Classes are things with responsibilities
Abstraction
Encapsulation
Inheritance
Polymorphism

The bad in its “definition”
Usually defined as data hiding

The ugliness is in our usage
Still functionally decomposing
Caused by it’s natural roots
Data hiding view
Data - functionality separation

E as hiding
Instead think of E as
Hiding – any kind of hiding
Implementation
Derived classes
Design details
Instantiation rules
Hide things
Why? What you hide you can change

E as hiding

The evil of the global variable
The lowest degree of encapsulation
Foo.field same as Global.field
Ignores all the efforts of C#/Java creators
Tight coupling

To depend on field a Foo is necessary
Coupling through field requires a reference to the same instance of Foo
Removing ‘public’ is another encapsulating action

E of member identity
Bar coupled to:
field’ ’s value
fieldis an integer
field is an instance member of Foo
Identity coupling: A knows that B exists

Create method/property that E field ’s nature
Bar is coupled only to the fact that
Prop is an integer property
Bar is decoupled from the fact that:
field is an integer
field is in Foo
field is stored anywhere at all

Self-Encapsulating members
Standard practice for accessing a field within the class itself is to refer to it directly

E of type
Hiding of entire types
CalcUser contains no mention of Adder or Multiplier
Calculator E its subclasses
GOF – “design to interfaces”

E of design
Someone has to new Adder or Multiplier
Someone has to decide which one to build
Client having this responsibility
Breaks the E of type
Lose modularity
Object factory

E of design
The Strategy Pattern itself is not E
If design changes
Hide the design
Context requests Strategy from StrategyFactory instead of Client
Have a factory build the Context object handing proper Strategy

E of variation
Animals
Types of moving
Walking
Flying
Switches
Subclasses
More variation
Herbivores
Carnivores

E of variation

Difficulty of E reference objects
**Demo**

Difficulty of E reference objects
myFoo is not fully encapsulated
Bar ’s behavior depends on the state of Foo reference
Client can break E if it retains the Foo reference

Breaking E

Breaking E
Tell don’t ask
Still exposes internal structure of the component
Client has to manage explicitly
Hide how money are displayed

Issues in E
We might say:
“Encapsulate the name of the application’s log file in the PricingPolicy class.”
Recast in terms of information hiding:
“Hide the name of the application’s log file in the PricingPolicy class.”
Information can be hidden in the wrong place

Values in E
Promotes
High cohesion
Freedom in changing things
Clarity
Low coupling
Testability

Resources
Design Patterns Explained
A New Perspective on
Object-Oriented Design
Design Patterns
Elements of Reusable
Object-Oriented Software
Code Complete

Please fill the evaluation form
Thank you very much
EigelSilviu-Horea,
silviu.eigel@endava.com

Encapsulation CodeCampIasi 16 oct 2010

by CodeCamp/Iasi on Oct 18, 2010

Accessibility

Categories

Upload Details

Usage Rights

Statistics

Encapsulation CodeCampIasi 16 oct 2010 — Presentation Transcript