principles:information_hiding_encapsulation
This is an old revision of the document!
Table of Contents
Information Hiding/Encapsulation (IH/E)
Variants and Alternative Names
- Parnas' Law1)
Context
Principle Statement
Description
Rationale
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
Evidence
Relations to Other Principles
Generalizations
Specializations
Contrary Principles
- Keep It Simple Stupid (KISS): Not adhering to IH/E is often easier.
Complementary Principles
- 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. - 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.
- 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.
Principle Collections
Examples
Description Status
Further Reading
1)
Anbert Endres, Dieter Rombach: A Handbook of Software and Systems Engineering
principles/information_hiding_encapsulation.1365106755.txt.gz · Last modified: 2013-05-19 22:10 (external edit)