Differences

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

--- principles:information_hiding_encapsulation [2021-02-02 02:51] – old revision restored (2021-02-01 19:17) 95.216.157.202
+++ principles:information_hiding_encapsulation [2021-02-02 18:58] – old revision restored (2020-12-10 07:39) 95.216.157.202
@@ Line 2: / Line 2: @@
 ===== Variants and Alternative Names =====
+  * Parnas' Law((Anbert Endres, Dieter Rombach: //A Handbook of Software and Systems Engineering//))
@@ Line 19: / Line 21: @@
 ===== Strategies =====
+  * Use the lowest possible visibility for a variable or method
+    * Make all attributes private and use getter and setter methods to access them
+    * Better also avoid getters and setters
+    * Find suitable abstractions for data types and use appropriate methods instead of just getters and setters
+  * Avoid aliasing problems with value objects
+    * 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.
+    * 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 =====
+See section [[#contrary principles]].
 ===== Origin =====
+David Parnas: //On the Criteria To Be Used in Decomposing Systems into Modules//
@@ Line 32: / Line 51: @@
   * [[wiki:Questioned]]
 */
 ===== Relations to Other Principles =====
@@ Line 41: / Line 61: @@
 ==== Contrary Principles ====
-  * [[principles:Keep It Simple Stupid]]
+  * [[Keep It Simple Stupid]] (KISS): Not adhering to IH/E is often easier.
 ==== Complementary Principles ====
-  * [[principles:Model Principle]]
+  * [[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.
-  * [[principles:Liskov Substitution Principle]]
+  * [[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.
-  * [[principles:Invariant Avoidance Principle]]
+  * [[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.
-  * [[principles:Information Expert]]
+  * [[Low Coupling]] (LC): Higher forms of couplings (especially content couplings) break encapsulation.
-  * [[principles:Low Coupling]]
+  * [[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.
-  * [[principles:Principle of Separate Upderstandability]]
+  * [[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 ====
@@ Line 58: / Line 79: @@
-===== Example =====
+===== Examples =====
@@ Line 66: / Line 87: @@
 /*[[wiki:Incomplete]]*/
 /*[[wiki:Complete]]*/
 ===== 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]]