Principles Wiki

User Tools

Site Tools

You are here: Principles Wiki » Principles » Information Hiding/Encapsulation (IH/E)
principles:information_hiding_encapsulation

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
principles:information_hiding_encapsulation [2020-10-12 16:17] – old revision restored (2013-03-11 17:30) 159.69.186.191principles:information_hiding_encapsulation [2020-10-12 16:17] – old revision restored (2013-02-18 17:24) 159.69.186.191
Line 20: Line 20:
 ===== Strategies ===== ===== Strategies =====
  
-  * Use the lowest possible visibility for a variable or method +  * Make all attributes private and use getter and setter methods to access them 
-    * Make all attributes private and use getter and setter methods to access them +  * Better also avoid getters and setters 
-    * Better also avoid getters and setters +  * Find suitable abstractions for data types and use appropriate methods instead of just getters and setters 
-    * Find suitable abstractions for data types and use appropriate methods instead of just getters and setters +  * Generally use the lowest possible visibility for a variable or method 
-  * Avoid aliasing problems with value objects +  * Use immutable objects or (if the programming language supports that) call-by-value objects (like stack objects in C++, structs in C#, records in Delphi, etc.) for value objects like ''Date'', ''Money'', ''EMailAddress'', ''TelephoneNumber'', etc. instead of mutable objects which handled are call-by-reference 
-    * If the programming language supports that use call-by-value objects (like stack objects in C++, structs in C#, records in Delphi, etc.) for value objects like ''Date'', ''Money'', ''EMailAddress'', ''TelephoneNumber'', etc.  +  * Copy internal list objects before returning them or only return a read-only ''interface'' for them
-    * Otherwise use immutable objects which are handled call-by-reference but needn't be copied +
-  * Avoid aliasing problems with lists and similar data structures +
-    * Copy internal list objects before returning them or only return a read-only ''interface'' to them +
 ===== Caveats ===== ===== Caveats =====
  
Line 61: Line 57:
   * [[Model Principle]] (MP): IH/E demands having an interface for a module which hides the inner workings. MP tells how such an interface can look like.   * [[Model Principle]] (MP): IH/E demands having an interface for a module which hides the inner workings. MP tells how such an interface can look like.
   * [[Liskov Substitution Principle]] (LSP): For subclasses you can waken encapsulation by having a wider ''protected'' interface which can be used by subclasses. For these cases LSP has to be considered, too.   * [[Liskov Substitution Principle]] (LSP): For subclasses you can waken encapsulation by having a wider ''protected'' interface which can be used by subclasses. For these cases LSP has to be considered, too.
 +  * [[Invariant Avoidance Principle]] (IAP): FIXME
   * [[Tell, don't Ask/Information Expert]] (TdA/IE): Encapsulation is about not having getter methods returning constituent internal parts of a module. TdA can be another reason for that.   * [[Tell, don't Ask/Information Expert]] (TdA/IE): Encapsulation is about not having getter methods returning constituent internal parts of a module. TdA can be another reason for that.
   * [[Low Coupling]] (LC): Higher forms of couplings (especially content couplings) break encapsulation.   * [[Low Coupling]] (LC): Higher forms of couplings (especially content couplings) break encapsulation.
principles/information_hiding_encapsulation.txt · Last modified: 2021-10-18 21:56 by christian