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

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

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

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

5. Back in the days Professor and students Functional decomposition Lasagna

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

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

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

9. 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

10. E as hiding

11. 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

12. 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

13. The evil of the global variable

14. 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

15. E of member identity

16. E of member identity 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

17. E of member identity

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

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

20. 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

21. 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

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

23. E of variation

24. Difficulty of E reference objects **Demo**

25. 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

26. Breaking E

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

28. 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

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

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

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