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
principles:information_hiding_encapsulation [2013-02-25 13:30] – [Strategies] christianprinciples:information_hiding_encapsulation [2021-10-18 21:56] (current) – +++ restored +++ christian
Line 2: Line 2:
  
 ===== Variants and Alternative Names ===== ===== Variants and Alternative Names =====
 +
 +  * Parnas' Law(({{page>resources:A Handbook of Software and Systems Engineering#reference}}))
  
  
 ===== Context ===== ===== Context =====
 /* fill in contexts here: */ /* fill in contexts here: */
-  * [[contexts:Object-Oriented Design]] +  * [[contexts:Object-Oriented Design]] 
 +  * [[contexts:API Design]] 
 +  * [[contexts:Architecture]] 
  
  
 ===== Principle Statement ===== ===== Principle Statement =====
 +
 +Modules should be [[glossary:encapsulation|encapsulated]].
  
  
 ===== Description ===== ===== Description =====
 +
 +Information hiding and encapsulation are sometimes seen as one and sometimes as two separate but related notions(({{page>resources:Encapsulation is not Information Hiding#reference}})). This varies through literature. There are three stages of information hiding/encapsulation which can be defined as having a capsule, making the capsule opaque, and making the capsule impenetrable.
 +
 +Having a capsule means that an object has methods which enable the client of the module to use it without accessing its internal data structures. Making the capsule opaque means that the inner workings are hidden from the clients. This is typically done by using access modifiers (private, protected). Lastly making the capsule impenetrable means that no client should be able to get a direct reference to an internal data structure.
 +
 +A properly encapsulated module with an impenetrable capsule is better than an module with just an opaque capsule. And this is better than a module with a non-opaque capsule. But at least having a capsule is better than not having one at all.
  
  
 ===== Rationale ===== ===== Rationale =====
  
 +When the inner workings of a module are hidden from the outside, then they can be changed without any other module noticing it. If the interface of the module stays the same, the rest of the system is not affected by the change. So adhering to IH/E prevents [[glossary:ripple effects]].
  
 ===== Strategies ===== ===== Strategies =====
Line 29: Line 43:
   * 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 37: Line 52:
 ===== Origin ===== ===== Origin =====
  
 +{{page>resources:On the Criteria To Be Used in Decomposing Systems into Modules#reference}}
  
 ===== Evidence ===== ===== Evidence =====
 /* Comment out what is not applicable and explain the rest: */ /* Comment out what is not applicable and explain the rest: */
-/* + 
-  * [[wiki:Proposed]] +/*  * [[wiki:Proposed]]*/ 
-  * [[wiki:Examined]] +/*  * [[wiki:Examined]]*/ 
-  * [[wiki:Accepted]] + 
-  * [[wiki:Questioned]] +  * [[wiki:Accepted]]: Virtually every book on object-orientation (e.g. (({{page>resources:Applying UML and Patterns#reference}})) explains IH/E to some extend. 
-*/+ 
 +/*  * [[wiki:Questioned]]*/ 
 + 
  
 ===== Relations to Other Principles ===== ===== Relations to Other Principles =====
Line 61: Line 80:
   * [[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 73: Line 92:
  
  
-===== Example =====+===== Examples =====
  
 +==== Example 1: Date and Time ====
 +
 +In Delphi there is the data structure ''TDateTime'' which represents a specific date and time value ((http://docwiki.embarcadero.com/Libraries/XE3/en/System.TDateTime)). This is an alias name for a double value where the integer part represents the number of days since December 30, 1899 and the fractional part represents the time of day. This alone is a data structure but it is not encapsulated.
 +
 +The Delphi runtime library (RTL) now specifies functions which operate on ''TDateTime'' structures. This is "having a capsule". But since it is still possible to access the internal representation directly, the inner workings are not hidden.
 +
 +This is different in Java. Here the inner workings are hidden. It is not possible to access the private attributes of ''java.util.Date''((http://docs.oracle.com/javase/7/docs/api/java/util/Date.html)). Here the capsule is opaque (and impenetrable).
 +
 +==== Example 2: Aliasing ====
 +
 +A typical example for an opaque but penetrable capsule is the following:
 +
 +<code java>
 +class SomeClass
 +{
 + private SomethingDifferent innerObject;
 +
 + public SomethingDifferent getInnerObject()
 + {
 + return innerObject;
 + }
 +}
 +</code>
 +
 +In such a case the ''innerObject'' is private, which means it is hidden. But it is revealed by the getter method. In order to establish an impenetrable capsule, the object has to be copied:
 +
 +<code java>
 +class SomeClass
 +{
 + private SomethingDifferent innerObject;
 +
 + public SomethingDifferent getInnerObject()
 + {
 + return innerObject.clone();
 + }
 +}
 +</code>
  
 ===== Description Status ===== ===== Description Status =====
 /* Choose one of the following and comment out the rest: */ /* Choose one of the following and comment out the rest: */
-[[wiki:Stub]]+/*[[wiki:Stub]]*/
 /*[[wiki:Incomplete]]*/ /*[[wiki:Incomplete]]*/
-/*[[wiki:Complete]]*/+[[wiki:Complete]] 
  
 ===== Further Reading ===== ===== Further Reading =====
  
 +  * [[wiki>EncapsulationDefinition]]
 +  * [[wp>Encapsulation (object-oriented programming)]]
 +
 +  * [[wiki>InformationHiding]]
 +  * [[wp>Information hiding]]
 +
 +  * {{page>resources:Encapsulation is not Information Hiding#reference}}
 +  * [[wiki>EncapsulationIsNotInformationHiding]]
 +
 +  * [[wiki>OnDecomposingSystems]]
 +
 +===== Discussion =====
 +
 +Discuss this wiki article and the principle on the corresponding [[talk:principles:Information Hiding/Encapsulation|talk page]].
  
principles/information_hiding_encapsulation.1361795425.txt.gz · Last modified: 2013-05-20 12:46 (external edit)