Object Oriented Model - Learning Module

Loading content...

0/241

Encapsulation

The Principle of Information Hiding

In 1972, David Parnas published his seminal paper 'On the Criteria to Be Used in Decomposing Systems into Modules,' introducing a principle that would become foundational to object-oriented programming: information hiding. The core insight was revolutionary yet simple—modules should reveal as little as possible about their internal workings.

Encapsulation is the mechanism that enforces information hiding. It bundles data (attributes) together with the operations (methods) that manipulate that data, while restricting direct access to some of the object's components. This isn't mere organizational convenience—it's a fundamental design principle with profound implications:

Data integrity — External code cannot corrupt internal state
Interface stability — Internal changes don't break external code
Reduced complexity — Users see only what they need to see
Enhanced maintainability — Implementation can evolve freely behind stable interfaces

In database systems, where data persistence spans years or decades, encapsulation isn't optional—it's essential for sustainable system evolution.

What You Will Learn

By the end of this page, you will understand how encapsulation works in object-oriented databases: access control levels, the public interface versus private implementation distinction, how methods serve as data guardians, and why encapsulation fundamentally changes how we think about database schema design.

The Encapsulation Principle

Encapsulation rests on a fundamental distinction: the interface (what an object does) versus the implementation (how it does it). Users of an object interact only with its interface; the implementation is hidden.

The Capsule Metaphor:

Think of an object as a capsule or cell. The outer membrane (interface) has carefully controlled openings—methods that the outside world can invoke. Inside the capsule, the internal mechanisms (attributes, helper methods, state transitions) operate according to their own rules. External entities cannot reach through the membrane to directly manipulate internals.

This creates two distinct zones:

Public Interface

•Visible to all external code
•Stable over time (breaks clients if changed)
•Defines the object's capabilities
•Documents what the object promises
•Methods that accept and return values

Private Implementation

•Hidden from external code
•Can change freely (no external dependencies)
•Contains raw data and internal logic
•May use complex algorithms or structures
•Helper methods and internal state

Why This Matters for Databases:

In traditional relational databases, data is exposed directly. Any application can read any column, write any value (if authorized), and depends directly on the physical schema. Change a column name or type, and every application breaks.

In encapsulated object databases:

Applications call methods, not accessing columns directly
The object validates all modifications
Schema changes can be handled within the object, invisibly to applications
Data integrity is guaranteed by design, not by scattered application logic

The Contract Concept

An object's public interface is a CONTRACT. It promises: 'Call these methods with these parameters, and I guarantee these behaviors.' As long as the contract is honored, everything inside can change—data structures, algorithms, even the underlying storage format.

Access Control Levels

Encapsulation isn't binary (all-or-nothing). Most object-oriented systems provide graduated access control levels that offer different degrees of visibility. Understanding these levels is essential for designing well-encapsulated database objects.

Standard Access Control Levels
Level	Visibility	Use Case	Example
private	Only within the same class	Internal state, helper methods, implementation details	Cached computed values, internal counters
protected	Same class + subclasses	Attributes that subclasses need to customize or extend	Template method components, extension points
package/internal	Same package or module	Implementation shared across related classes	Utility methods used by sibling classes
public	Visible to all code	The object's external interface	Business operations, query methods

Access Level Examples
ODL/Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
class BankAccount {
    // Private: internal state, never directly accessible
    private float balance;
    private List<Transaction> transactionLog;
    private Date lastModified;
    
    // Protected: subclasses may need to adjust
    protected float overdraftLimit = 0.0f;
    protected float interestRate;
    
    // Public: the account's external interface
    public float getBalance() {
        return balance;
    }
    
    public void deposit(float amount) {
        validatePositive(amount);
        balance += amount;
        logTransaction("DEPOSIT", amount);
        lastModified = now();
    }
    
    public void withdraw(float amount) {
        validatePositive(amount);
        validateSufficientFunds(amount);
        balance -= amount;
        logTransaction("WITHDRAWAL", amount);
        lastModified = now();
    }
    
    public List<Transaction> getRecentTransactions(int count) {
        // Returns a COPY, not the internal list
        return transactionLog.slice(-count).copy();
    }
    
    // Private helper methods
    private void validatePositive(float amount) {
        if (amount <= 0) {
            throw new InvalidAmountException("Amount must be positive");
        }
    }
    
    private void validateSufficientFunds(float amount) {
        if (amount > balance + overdraftLimit) {
            throw new InsufficientFundsException();
        }
    }
    
    private void logTransaction(String type, float amount) {
        transactionLog.add(new Transaction(type, amount, now()));
    }
}
 
class PremiumAccount extends BankAccount {
    // Can access protected members from parent
    public void setPreferredRate(float rate) {
        this.interestRate = rate;  // OK: protected
        this.overdraftLimit = 5000;  // OK: protected
    }
    
    // Cannot access private members
    // this.balance = 1000000;  // ERROR: private
}
 
// External code can only use public interface
BankAccount account = getAccount("12345");
account.deposit(100);     // OK: public method
account.withdraw(50);     // OK: public method
float bal = account.getBalance();  // OK: public method
 
// account.balance = 1000000;  // ERROR: private attribute
// account.validatePositive(x);  // ERROR: private method

Language Variations

Different languages offer slightly different access levels. Python uses naming conventions (underscore prefix). C++ has additional friend declarations. JavaScript uses closures or private class fields. OODBMS systems typically support at least private/public, with some offering full granularity.

Methods as Data Guardians

In encapsulated objects, methods are more than operations—they are guardians that protect data integrity. Every modification to state passes through methods that can validate, transform, log, and ensure consistency.

The Guardian Pattern:

Instead of allowing direct attribute access:

employee.salary = -50000  // Invalid state: negative salary!

We channel all modifications through methods:

employee.setSalary(-50000)  // Method throws exception
employee.adjustSalary(newAmount, reason)  // Validates, logs, audits

This seemingly small change has enormous implications:

What Guardian Methods Enable

•Validation — Reject invalid values before they corrupt state. A temperature attribute can reject values below absolute zero.
•Normalization — Transform input to canonical form. An email setter can lowercase all characters, trim whitespace.
•Dependent Updates — Maintain consistency across related attributes. Changing order status to 'shipped' automatically sets ship date.
•Audit Logging — Record who changed what, when, and why. Every salary change logs the authorizer and justification.
•Event Triggering — Notify observers of state changes. Setting account balance below threshold triggers low-balance alert.
•Access Control — Verify the caller has permission for this specific operation on this specific object.
•Invariant Enforcement — Ensure object-wide constraints remain satisfied after every modification.

Guardian Methods in Practice
ODL/Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
class Employee {
    private String name;
    private float salary;
    private Department department;
    private String email;
    private Date terminationDate;
    private String status;  // "ACTIVE", "ON_LEAVE", "TERMINATED"
    
    // Guardian method with full validation
    public void adjustSalary(float newSalary, String reason, User authorizer) {
        // 1. Validate: salary must be positive
        if (newSalary < 0) {
            throw new ValidationException("Salary cannot be negative");
        }
        
        // 2. Access control: only managers can adjust salary
        if (!authorizer.hasPermission("SALARY_ADJUSTMENT")) {
            throw new SecurityException("Not authorized for salary adjustment");
        }
        
        // 3. Business rule: max 50% increase without VP approval
        float percentChange = (newSalary - salary) / salary * 100;
        if (percentChange > 50 && !authorizer.hasRole("VP")) {
            throw new ApprovalRequiredException("VP approval required for >50% increase");
        }
        
        // 4. Audit logging
        auditLog.record(new SalaryChange(
            this.id, 
            salary, 
            newSalary, 
            reason, 
            authorizer, 
            now()
        ));
        
        // 5. Event notification
        eventBus.publish(new SalaryChangedEvent(this, salary, newSalary));
        
        // 6. Finally: update state
        this.salary = newSalary;
    }
    
    // Guardian method maintaining invariants
    public void setEmail(String newEmail) {
        // Normalize input
        String normalized = newEmail.toLowerCase().trim();
        
        // Validate format
        if (!isValidEmailFormat(normalized)) {
            throw new ValidationException("Invalid email format");
        }
        
        // Check uniqueness (database-level constraint)
        if (Employee.existsWithEmail(normalized) && 
            !normalized.equals(this.email)) {
            throw new DuplicateException("Email already in use");
        }
        
        this.email = normalized;
    }
    
    // Guardian method with dependent updates
    public void terminate(Date effectiveDate, String reason) {
        if (this.status == "TERMINATED") {
            throw new InvalidStateException("Already terminated");
        }
        
        this.status = "TERMINATED";
        this.terminationDate = effectiveDate;
        this.department.removeEmployee(this);  // Update relationship
        
        // Clean up related objects
        for (Project p : this.assignedProjects) {
            p.reassignTasks(this);
        }
        
        auditLog.record(new TerminationRecord(this, effectiveDate, reason));
        notifyHR(this, "TERMINATION");
    }
}

Getter/Setter Anti-Pattern

Simply wrapping every attribute with trivial get/set methods (getX() { return x; } setX(v) { x = v; }) provides no real encapsulation—it's just syntactic overhead. True encapsulation means meaningful methods that represent domain operations: adjustSalary(), terminate(), assignToProject()—not setSalary(), setStatus(), setProject().

Encapsulation vs Relational Exposure

The fundamental difference between object-oriented and relational databases regarding encapsulation cannot be overstated. Relational databases expose data; object databases expose behavior.

The Relational Reality:

In a relational database, applications have direct access to tables and columns. Any application with SELECT permission can read any column. Any application with UPDATE permission can modify any column to any value (subject to constraints). The database is a passive store that applications read from and write to.

Constraints exist (NOT NULL, CHECK, FOREIGN KEY), but they're:

Limited in expressiveness
Separate from any notion of 'operations'
Easily bypassed by those with sufficient privileges

Data Access: Relational vs Object-Oriented
Aspect	Relational Database	Object-Oriented Database
Data access	Direct column read/write via SQL	Through method calls on objects
Validation location	CHECK constraints + application code	Encapsulated in object methods
Business logic	Stored procedures OR application tier	In object methods, with data
Schema visibility	Complete schema visible to applications	Only public interface visible
Coupling	Applications coupled to physical schema	Applications coupled to logical interface
Change impact	Schema change breaks applications	Internal change invisible to applications

Relational vs Object Access
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
-- Relational: Applications directly manipulate data
-- Application 1:
UPDATE Employee SET salary = 100000 WHERE id = 123;
 
-- Application 2 (different team, same table):
UPDATE Employee SET salary = salary * 1.5 WHERE id = 123;
 
-- Application 3 (forgot validation):
UPDATE Employee SET salary = -50 WHERE id = 123;  -- Oops!
 
-- Business rules scattered across:
--   - Application 1 code
--   - Application 2 code  
--   - Database CHECK constraints
--   - Trigger procedures
--   - API middleware
 
-- Schema change: rename salary -> compensation
-- Result: ALL applications break simultaneously

Real-World Impact

Large organizations with dozens of applications accessing shared databases spend enormous effort on 'data governance'—trying to ensure all applications follow the same rules. Encapsulation solves this architecturally: the rules are IN the objects, enforced by the database itself, not scattered across application codebases.

Information Hiding in Practice

Information hiding goes beyond access control—it's about presenting a simplified model to users while hiding complexity. Let's explore practical applications in database objects.

Computed Attributes:

An object can present attributes that don't correspond to stored data. The user asks for employee.yearsOfService—they don't know (or care) if this is:

Stored directly (denormalized)
Computed from hireDate on every access
Cached with lazy recomputation
Retrieved via a complex calculation involving multiple internal fields

Information Hiding Patterns
ODL/Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
class Employee {
    // HIDDEN: The actual storage structure
    private Date hireDate;
    private int cachedYearsOfService;
    private Date cacheDate;
    
    // EXPOSED: Simple interface
    public int getYearsOfService() {
        // Implementation detail: caching strategy
        if (cacheDate == null || daysSince(cacheDate) > 30) {
            cachedYearsOfService = calculateYears(hireDate, today());
            cacheDate = today();
        }
        return cachedYearsOfService;
    }
    
    // User sees: employee.yearsOfService → 5
    // User doesn't see: caching, calculation, date arithmetic
}
 
class Order {
    // HIDDEN: Complex internal state
    private List<OrderItem> items;
    private Map<String, Discount> appliedDiscounts;
    private TaxCalculator taxEngine;
    private Currency currency;
    private ExchangeRateService rateService;
    
    // EXPOSED: Simple interface
    public Money getTotal() {
        Money subtotal = calculateSubtotal();
        Money discounts = calculateDiscounts();
        Money tax = calculateTax(subtotal - discounts);
        return subtotal - discounts + tax;
    }
    
    public Money getTotalInCurrency(Currency targetCurrency) {
        Money total = getTotal();
        if (targetCurrency == this.currency) {
            return total;
        }
        return rateService.convert(total, this.currency, targetCurrency);
    }
    
    // User sees: order.total → $127.50
    // Hidden complexity: item aggregation, discount rules, 
    //   tax jurisdictions, currency conversion
}
 
class Account {
    // HIDDEN: Versioned history storage
    private List<BalanceSnapshot> balanceHistory;
    private Balance currentBalance;
    
    // EXPOSED: Simple point-in-time query
    public Money getBalance() {
        return currentBalance.amount;
    }
    
    public Money getBalanceAsOf(Date date) {
        // Complex historical lookup hidden from user
        return balanceHistory
            .filter(s -> s.timestamp <= date)
            .sortByTimestamp()
            .last()
            .amount;
    }
    
    // User sees: account.balanceAsOf(lastYear) → $50,000
    // Hidden: temporal data structure, snapshot interpolation
}

Presentation Independence:

Information hiding allows objects to present data differently from how it's stored:

Internal Storage	External Presentation
`firstName`, `lastName`	`fullName`
Cents (int)	Dollars (decimal)
UTC timestamp	Local time with timezone
Compressed binary	Decompressed string
Normalized tables	Denormalized object
Legacy format	Modern API

Migration Path

Information hiding enables seamless data migrations. You can change storage format (e.g., from single 'name' field to 'firstName'/'lastName' fields) while maintaining the same public interface. Old code calling getName() keeps working; new code can call getFirstName() if needed.

Encapsulation and Integrity Constraints

Object encapsulation provides a powerful mechanism for enforcing invariants—conditions that must always be true for an object to be in a valid state. Unlike relational CHECK constraints (which are limited to SQL expressions), object invariants can be arbitrarily complex.

Class Invariants:

A class invariant is a condition involving the object's state that must hold:

After construction (object is born valid)
Before and after every public method call
At all externally observable points

Class Invariants
ODL/Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
class DateRange {
    private Date startDate;
    private Date endDate;
    
    // Invariant: startDate <= endDate (always!)
    
    // Constructor establishes invariant
    public DateRange(Date start, Date end) {
        if (start > end) {
            throw new InvalidRangeException("Start must be before end");
        }
        this.startDate = start;
        this.endDate = end;
        // Invariant now holds
    }
    
    // Every mutator maintains invariant
    public void setStartDate(Date newStart) {
        if (newStart > endDate) {
            throw new InvalidRangeException("Start cannot be after end");
        }
        this.startDate = newStart;
        // Invariant still holds
    }
    
    public void setEndDate(Date newEnd) {
        if (newEnd < startDate) {
            throw new InvalidRangeException("End cannot be before start");
        }
        this.endDate = newEnd;
        // Invariant still holds
    }
    
    public void shift(int days) {
        // Both move together - invariant trivially maintained
        this.startDate = startDate.plusDays(days);
        this.endDate = endDate.plusDays(days);
    }
}
 
class Account {
    private float balance;
    private float creditLimit;
    private AccountStatus status;
    
    // Invariants:
    //   1. balance >= -creditLimit
    //   2. if status == CLOSED then balance == 0
    //   3. creditLimit >= 0
    
    public void withdraw(float amount) {
        if (amount <= 0) {
            throw new InvalidAmountException();
        }
        if (status == AccountStatus.CLOSED) {
            throw new AccountClosedException();
        }
        if (balance - amount < -creditLimit) {  // Invariant 1
            throw new InsufficientFundsException();
        }
        this.balance -= amount;
        // All invariants maintained
    }
    
    public void close() {
        if (balance != 0) {  // Invariant 2
            throw new NonZeroBalanceException(
                "Clear balance before closing"
            );
        }
        this.status = AccountStatus.CLOSED;
        this.creditLimit = 0;
        // All invariants maintained
    }
}

Multi-Object Invariants:

Some invariants span multiple objects. Encapsulation handles these through coordinated methods:

class Department {
    private Set<Employee> employees;
    private Employee manager;  // Must be in employees set!
    
    public void setManager(Employee emp) {
        if (!employees.contains(emp)) {
            throw new InvalidManagerException(
                "Manager must be a department employee"
            );
        }
        this.manager = emp;
    }
    
    public void removeEmployee(Employee emp) {
        if (emp == manager) {
            throw new ConstraintViolationException(
                "Cannot remove department manager"
            );
        }
        employees.remove(emp);
    }
}

Transaction Boundaries

Multi-object invariants must be checked at transaction commit, not just per-operation. The invariant 'manager is in employees' could be temporarily violated if you remove the old manager, then add the new one—both within the same transaction. OODBMS must support deferred constraint checking.

Encapsulation Benefits for Databases

Let's consolidate why encapsulation matters specifically for database systems—beyond its general software engineering benefits.

Database-Specific Benefits

•Schema Evolution — Internal storage can change (add columns, change types, denormalize) without affecting applications. The public interface absorbs changes invisibly.
•Performance Optimization — Indexing strategies, caching, lazy loading, and prefetching can be changed internally. Applications don't need to know if data is cached or freshly computed.
•Security Enforcement — Access control is method-level, not row/column-level. An employee can update their own address without having broad UPDATE permission on the Employee table.
•Audit Completeness — All modifications pass through methods. Comprehensive audit logging is guaranteed, not dependent on application discipline.
•Business Rule Centralization — Rules live in object methods, updating in one place. No hunting through dozens of applications to fix a validation bug.
•Data Quality — Invalid data cannot enter the database. Validation happens before storage, not after (or never).
•Integration Simplification — External systems integrate with stable object interfaces. Schema details are abstracted away.

Long-Term System Health
Challenge	Without Encapsulation	With Encapsulation
Adding new validation rule	Find and update all applications	Update object method once
Changing storage format	Database migration + all apps	Database migration only
Performance optimization	Query changes across apps	Internal method optimization
Security audit	Review all application access	Review object methods
Bug investigation	Check all write paths	Check single method
New application integration	Understand full schema	Understand object interface

The 10-Year View

Database systems often outlive the applications that created them by decades. Encapsulation provides the insulation needed for sustainable evolution—the database can modernize internally while maintaining interfaces that legacy systems depend on.

Summary: Encapsulation

We've explored how encapsulation transforms database design. Let's consolidate the key insights:

Key Takeaways

•Encapsulation separates interface from implementation — Users see capabilities (methods), not internals (attributes).
•Access control levels provide graduated visibility — Private, protected, package, public control who sees what.
•Methods are guardians of data integrity — Validation, normalization, audit, and consistency enforced at single point.
•Relational databases expose data; object databases expose behavior — Fundamentally different architectural models.
•Information hiding simplifies presentations — Complex storage presents as simple interface.
•Invariants maintain object validity — Complex multi-attribute constraints enforced by method logic.
•Long-term maintainability improves — Schema evolution, optimization, security all benefit from encapsulation.

What's Next:

Now that we understand the three pillars of OO databases—objects, inheritance, and encapsulation—the next page explores Object-Relational Mapping (ORM). We'll see how modern systems bridge object-oriented programming with relational storage, bringing OO concepts to the dominant database paradigm.

Page Complete

You now understand how encapsulation protects data, simplifies interfaces, and enables sustainable database evolution. This principle—perhaps more than any other—distinguishes object thinking from relational thinking. Next, we bridge these worlds with Object-Relational Mapping.