Encapsulation and abstraction working together

Encapsulation in structured systems analysis and design

In structured analysis and design (SSAD), a system is built from processes (functions) acting on data (data stores, data flows) that are kept separately. The data is global or passed around freely, and any process can read or change it. So in SSAD there is no true encapsulation. The nearest idea is information hiding (modularity): a module (a bubble in a DFD or a box in a structure chart) hides how it works internally and shows only its inputs and outputs. The data it works on, however, is not owned or protected by that module.

Encapsulation in the object-oriented sense goes further: it binds data and the operations on that data into one unit (the object) and restricts direct access to the data from outside.

How encapsulation and abstraction work together

• Abstraction is the outside view: it focuses on the essential characteristics of an object that matter to the user and ignores the rest. It answers "what does the object do?"
• Encapsulation is the inside view: it hides the implementation (data structure and algorithms) behind that abstraction. It answers "how is it done, and how is it protected?"

Abstraction decides the public interface; encapsulation enforces it by keeping everything else private. One is the design idea, the other is the mechanism that makes the idea hold.

   Client code
       |  withdraw(500), getBalance()
       v
 +----------------------------+
 |  BankAccount  (abstraction)|  <- public interface
 |----------------------------|
 |  - balance   (hidden)      |  <- encapsulated data
 |  - checkLimit() (hidden)   |  <- encapsulated logic
 +----------------------------+

Example: A client sees BankAccount only as something that can deposit(), withdraw() and getBalance() (abstraction). The balance field and the rule that the balance must not go below the minimum are private (encapsulation). The client cannot set balance = -1000. If the bank later changes how balance is stored, no client code changes.

Together they give: reduced complexity (user thinks only about the interface), safe data (invariants are protected), easy maintenance (implementation can change freely) and reuse of the class in many programs.