encapsulation codecampiasi 16 oct 2010
DESCRIPTION
TRANSCRIPT
Encapsulationthe good, the bad, the uglyEigel Silviu-Horea, [email protected]
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
