User Tools

Site Tools


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 [2013-06-15 15:31] – [Context] 94.217.39.37principles:information_hiding_encapsulation [2020-10-12 16:17] – old revision restored (2013-02-25 13:30) 159.69.186.191
Line 2: Line 2:
  
 ===== Variants and Alternative Names ===== ===== Variants and Alternative Names =====
- 
-  * Parnas' Law((Anbert Endres, Dieter Rombach: //A Handbook of Software and Systems Engineering//)) 
  
  
 ===== Context ===== ===== Context =====
 /* fill in contexts here: */ /* fill in contexts here: */
-  * [[contexts:Object-Oriented Design]] +  * [[contexts:Object-Oriented Design]] 
-  * [[contexts:API Design]] +
-  * [[contexts:Architecture]] +
  
  
Line 34: Line 29:
   * Avoid aliasing problems with lists and similar data structures   * 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     * Copy internal list objects before returning them or only return a read-only ''interface'' to them
- 
  
 ===== Caveats ===== ===== Caveats =====
Line 43: Line 37:
 ===== Origin ===== ===== Origin =====
  
-David Parnas: //[[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.132.7232|On the Criteria To Be Used in Decomposing Systems into Modules]]//+
 ===== Evidence ===== ===== Evidence =====
 /* Comment out what is not applicable and explain the rest: */ /* Comment out what is not applicable and explain the rest: */
Line 52: Line 46:
   * [[wiki:Questioned]]   * [[wiki:Questioned]]
 */ */
- 
  
 ===== Relations to Other Principles ===== ===== Relations to Other Principles =====
Line 68: Line 61:
   * [[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.
   * [[Principle of Separate Understandability]] (PSU): IH/E is about constructing a module in a way that hides the inner workings so it can be used without knowing them. PSU on the other hand is about constructing a module such that its inner workings (and its usage also) can be understood without knowledge about //other// modules.   * [[Principle of Separate Understandability]] (PSU): IH/E is about constructing a module in a way that hides the inner workings so it can be used without knowing them. PSU on the other hand is about constructing a module such that its inner workings (and its usage also) can be understood without knowledge about //other// modules.
   * [[Easy to Use and Hard to Misuse]] (EUHM): A module should be properly encapsulated in order to make it easy to use and hard to misuse.   * [[Easy to Use and Hard to Misuse]] (EUHM): A module should be properly encapsulated in order to make it easy to use and hard to misuse.
- 
  
 ==== Principle Collections ==== ==== Principle Collections ====
Line 80: Line 73:
  
  
-===== Examples =====+===== Example =====
  
  
Line 88: Line 81:
 /*[[wiki:Incomplete]]*/ /*[[wiki:Incomplete]]*/
 /*[[wiki:Complete]]*/ /*[[wiki:Complete]]*/
- 
  
 ===== Further Reading ===== ===== Further Reading =====
  
-  * [[wiki>EncapsulationDefinition]] 
-  * [[wp>Encapsulation (object-oriented programming)]] 
- 
-  * [[wiki>InformationHiding]] 
-  * [[wp>Information hiding]] 
- 
-  * [[http://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html|Java World: Encapsulation is not information hiding]] 
-  * [[wiki>EncapsulationIsNotInformationHiding]] 
  
-  * [[wiki>OnDecomposingSystems]] 
principles/information_hiding_encapsulation.txt · Last modified: 2021-10-18 21:56 by christian