Encapsulation CodeCampIasi 16 oct 2010

900 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
900
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Encapsulation CodeCampIasi 16 oct 2010

  1. 1. Encapsulationthe good, the bad, the ugly<br />EigelSilviu-Horea, silviu.eigel@endava.com<br /> www.endava.com<br />16 Octombrie2010<br />
  2. 2. Agenda<br />From functional decomposition to OOP<br />Encapsulation<br />From bad and ugly to “The Good”<br />Building up encapsulation<br />Handling variation<br />Conclusions<br />
  3. 3. Some values<br />Cohesion<br />How closely the operations in a module are related<br />Coupling <br />The strength of a <br />connection between <br />two modules<br />
  4. 4. Some problems<br />Requirements Always Change<br />Change is necessary<br />New variation to an existing theme<br />
  5. 5. Back in the days<br />Professor and students <br />Functional decomposition<br />Lasagna<br />
  6. 6. OOP<br />Objects as data with methods<br />Classes are things with responsibilities<br />Abstraction<br />Encapsulation<br />Inheritance<br />Polymorphism<br />
  7. 7. The bad in its “definition”<br />Usually defined as data hiding<br />
  8. 8. The ugliness is in our usage<br />Still functionally decomposing<br />Caused by it’s natural roots<br />Data hiding view<br />Data - functionality separation<br />
  9. 9. E as hiding<br />Instead think of E as<br />Hiding – any kind of hiding<br />Implementation<br />Derived classes<br />Design details<br />Instantiation rules<br />Hide things <br />Why? What you hide you can change<br />
  10. 10. E as hiding<br />
  11. 11. The evil of the global variable<br />The lowest degree of encapsulation<br />Foo.field same as Global.field<br />Ignores all the efforts of C#/Java creators<br />Tight coupling<br />
  12. 12. The evil of the global variable<br />To depend on field a Foo is necessary<br />Coupling through field requires a reference to the same instance of Foo<br />Removing ‘public’ is another encapsulating action<br />
  13. 13. The evil of the global variable<br />
  14. 14. E of member identity<br />Bar coupled to: <br />field’ ’s value<br />fieldis an integer<br />field is an instance member of Foo<br />Identity coupling: A knows that B exists<br />
  15. 15. E of member identity<br />
  16. 16. E of member identity<br />Create method/property that E field ’s nature<br />Bar is coupled only to the fact that <br />Prop is an integer property<br />Bar is decoupled from the fact that:<br />field is an integer<br />field is in Foo<br />field is stored anywhere at all<br />
  17. 17. E of member identity<br />
  18. 18. Self-Encapsulating members<br />Standard practice for accessing a field within the class itself is to refer to it directly<br />
  19. 19. E of type<br />Hiding of entire types<br />CalcUser contains no mention of Adder or Multiplier<br />Calculator E its subclasses<br />GOF – “design to interfaces”<br />
  20. 20. E of design<br />Someone has to new Adder or Multiplier<br />Someone has to decide which one to build<br />Client having this responsibility<br />Breaks the E of type<br />Lose modularity<br />Object factory<br />
  21. 21. E of design<br />The Strategy Pattern itself is not E<br />If design changes<br />Hide the design<br />Context requests Strategy from StrategyFactory instead of Client<br />Have a factory build the Context object handing proper Strategy<br />
  22. 22. E of variation<br />Animals<br />Types of moving<br />Walking<br />Flying<br />Switches<br />Subclasses<br />More variation<br />Herbivores<br />Carnivores<br />
  23. 23. E of variation<br />
  24. 24. Difficulty of E reference objects<br />**Demo**<br />
  25. 25. Difficulty of E reference objects<br />myFoo is not fully encapsulated<br />Bar ’s behavior depends on the state of Foo reference<br />Client can break E if it retains the Foo reference<br />
  26. 26. Breaking E<br />
  27. 27. Breaking E<br />Tell don’t ask<br />Still exposes internal structure of the component<br />Client has to manage explicitly<br />Hide how money are displayed<br />
  28. 28. Issues in E<br />We might say:<br />“Encapsulate the name of the application’s log file in the PricingPolicy class.”<br />Recast in terms of information hiding:<br />“Hide the name of the application’s log file in the PricingPolicy class.”<br />Information can be hidden in the wrong place<br />
  29. 29. Values in E<br />Promotes<br />High cohesion<br />Freedom in changing things<br />Clarity<br />Low coupling<br />Testability<br />
  30. 30. Resources<br />Design Patterns Explained <br />A New Perspective on <br />Object-Oriented Design <br />Design Patterns <br />Elements of Reusable <br />Object-Oriented Software<br />Code Complete<br />
  31. 31. Please fill the evaluation form<br />Thank you very much<br />EigelSilviu-Horea, <br />silviu.eigel@endava.com<br />

×