Your SlideShare is downloading. ×
Encapsulation
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Encapsulation

443
views

Published on

Published in: Technology, Business

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
443
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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