User Tools

Site Tools


principles:information_hiding_encapsulation

This is an old revision of the document!


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

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

OOD Principle Language
General Principles
ML KISS MIMC DRY GP RoE
Modularization Principles
MP HC ECV
Module Communication Principles
TdA/IE LC DIP
Interface Design Principles
EUHM PLS UP
Internal Module Design Principles
IH/E IAP LSP PSU

Examples

Description Status

Further Reading

1)
Anbert Endres, Dieter Rombach: A Handbook of Software and Systems Engineering
principles/information_hiding_encapsulation.1630579007.txt.gz · Last modified: 2021-09-02 12:36 by 65.21.179.175