principles:information_hiding_encapsulation
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
| principles:information_hiding_encapsulation [2013-06-15 15:31] – [Context] 94.217.39.37 | principles:information_hiding_encapsulation [2020-10-12 16:17] – old revision restored (2013-02-18 17:24) 159.69.186.191 | ||
|---|---|---|---|
| Line 2: | Line 2: | ||
| ===== Variants and Alternative Names ===== | ===== Variants and Alternative Names ===== | ||
| - | |||
| - | * Parnas' | ||
| ===== Context ===== | ===== Context ===== | ||
| /* fill in contexts here: */ | /* fill in contexts here: */ | ||
| - | * [[contexts: | + | * [[contexts: |
| - | * [[contexts: | + | |
| - | * [[contexts: | + | |
| Line 25: | Line 20: | ||
| ===== Strategies ===== | ===== Strategies ===== | ||
| - | | + | * 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 '' |
| - | * 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 '' | + | * Copy internal list objects before returning them or only return a read-only '' |
| - | * Otherwise use immutable | + | |
| - | | + | |
| - | | + | |
| - | + | ||
| ===== Caveats ===== | ===== Caveats ===== | ||
| Line 43: | Line 33: | ||
| ===== Origin ===== | ===== Origin ===== | ||
| - | David Parnas: // | + | |
| ===== 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 42: | ||
| * [[wiki: | * [[wiki: | ||
| */ | */ | ||
| - | |||
| ===== Relations to Other Principles ===== | ===== Relations to Other Principles ===== | ||
| Line 68: | 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 '' | * [[Liskov Substitution Principle]] (LSP): For subclasses you can waken encapsulation by having a wider '' | ||
| + | * [[Invariant Avoidance Principle]] (IAP): FIXME | ||
| * [[Tell, don't Ask/ | * [[Tell, don't Ask/ | ||
| * [[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 69: | ||
| - | ===== Examples | + | ===== Example |
| Line 88: | Line 77: | ||
| / | / | ||
| / | / | ||
| - | |||
| ===== Further Reading ===== | ===== Further Reading ===== | ||
| - | * [[wiki> | ||
| - | * [[wp> | ||
| - | |||
| - | * [[wiki> | ||
| - | * [[wp> | ||
| - | |||
| - | * [[http:// | ||
| - | * [[wiki> | ||
| - | * [[wiki> | ||
principles/information_hiding_encapsulation.txt · Last modified: 2021-10-18 21:56 by christian