Encapsulationthe good, the bad, the uglyEigel Silviu-Horea, silviu.eigel@endava.com

www.endava.com

16 Octombrie 2010

AgendaFrom functional decomposition to OOPEncapsulationFrom bad and ugly to “The Good”

Building up encapsulationHandling variation

Conclusions

Some valuesCohesion

How closely the operations in a module are related

Coupling The strength of a connection between two modules

Some problemsRequirements Always ChangeChange is necessaryNew variation to an existing theme

Back in the daysProfessor and students Functional decompositionLasagna

OOPObjects as data with methodsClasses are things with responsibilities

AbstractionEncapsulationInheritancePolymorphism

The bad in its “definition”

Usually defined as data hiding

The ugliness is in our usageStill functionally decomposingCaused by it’s natural roots

Data hiding viewData - functionality separation

E as hidingInstead think of E asHiding – any kind of hidingImplementationDerived classesDesign detailsInstantiation rules

Hide things Why? What you hide you can change

E as hiding

The evil of the global variableThe lowest degree of encapsulation

Foo.field same as Global.fieldIgnores all the efforts of C#/Java creators

Tight coupling

The evil of the global variable

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

The evil of the global variable

E of member identityBar coupled to: field’ ’s valuefield is an integerfield is an instance member of Foo

Identity coupling: A knows that B exists

E of member identity

E of member identityCreate 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 integerfield is in Foofield is stored anywhere at all

E of member identity

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

E of typeHiding of entire types

CalcUser contains no mention of Adder or Multiplier

Calculator E its subclasses

GOF – “design to interfaces”

E of designSomeone has to new Adder or MultiplierSomeone has to decide which one to buildClient having this responsibility

Breaks the E of type Lose modularity

Object factory

E of design

The Strategy Pattern itself is not E If design changesHide the design

Context requests Strategy from StrategyFactory instead of Client

Have a factory build the Context object handing proper Strategy

E of variationAnimalsTypes of moving

WalkingFlying

SwitchesSubclassesMore variation

HerbivoresCarnivores

E of variation

Difficulty of E reference objects**Demo**

Difficulty of E reference objectsmyFoo 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 ETell don’t ask

Still exposes internal structure of the component

Client has to manage explicitly

Hide how money are displayed

Issues in EWe 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 EPromotesHigh cohesionFreedom in changing thingsClarityLow couplingTestability

ResourcesDesign Patterns Explained A New Perspective on Object-Oriented Design Design Patterns Elements of Reusable Object-Oriented SoftwareCode Complete

Please fill the evaluation form

Thank you very much

Eigel Silviu-Horea, silviu.eigel@endava.com