Encapsulation CodeCampIasi 16 oct 2010
Upcoming SlideShare
Loading in...5
×
 

Encapsulation CodeCampIasi 16 oct 2010

on

  • 825 views

 

Statistics

Views

Total Views
825
Views on SlideShare
825
Embed Views
0

Actions

Likes
0
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Encapsulation CodeCampIasi 16 oct 2010 Encapsulation CodeCampIasi 16 oct 2010 Presentation Transcript

    • Encapsulationthe good, the bad, the ugly
      EigelSilviu-Horea, silviu.eigel@endava.com
      www.endava.com
      16 Octombrie2010
    • Agenda
      From functional decomposition to OOP
      Encapsulation
      From bad and ugly to “The Good”
      Building up encapsulation
      Handling variation
      Conclusions
    • Some values
      Cohesion
      How closely the operations in a module are related
      Coupling
      The strength of a
      connection between
      two modules
    • Some problems
      Requirements Always Change
      Change is necessary
      New variation to an existing theme
    • Back in the days
      Professor and students
      Functional decomposition
      Lasagna
    • OOP
      Objects as data with methods
      Classes are things with responsibilities
      Abstraction
      Encapsulation
      Inheritance
      Polymorphism
    • The bad in its “definition”
      Usually defined as data hiding
    • The ugliness is in our usage
      Still functionally decomposing
      Caused by it’s natural roots
      Data hiding view
      Data - functionality separation
    • 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
    • E as hiding
    • 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
    • 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 identity
      Bar coupled to:
      field’ ’s value
      fieldis an integer
      field is an instance member of Foo
      Identity coupling: A knows that B exists
    • E of member identity
    • 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
    • E of member identity
    • Self-Encapsulating members
      Standard practice for accessing a field within the class itself is to refer to it directly
    • E of type
      Hiding of entire types
      CalcUser contains no mention of Adder or Multiplier
      Calculator E its subclasses
      GOF – “design to interfaces”
    • 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
    • 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
    • E of variation
      Animals
      Types of moving
      Walking
      Flying
      Switches
      Subclasses
      More variation
      Herbivores
      Carnivores
    • E of variation
    • Difficulty of E reference objects
      **Demo**
    • 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
    • Breaking E
    • Breaking E
      Tell don’t ask
      Still exposes internal structure of the component
      Client has to manage explicitly
      Hide how money are displayed
    • 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
    • Values in E
      Promotes
      High cohesion
      Freedom in changing things
      Clarity
      Low coupling
      Testability
    • Resources
      Design Patterns Explained
      A New Perspective on
      Object-Oriented Design
      Design Patterns
      Elements of Reusable
      Object-Oriented Software
      Code Complete
    • Please fill the evaluation form
      Thank you very much
      EigelSilviu-Horea,
      silviu.eigel@endava.com