Encapsulation OOP Basics – Visibility, Information Hiding, private, protected, public

This post is a definition of terms on encapsulation in OOP – including exam questions and tags.

In a Nutshell

Encapsulation hides the internal states and implementation details of an object, with only well-defined interfaces visible to the outside. The goal is robust, maintainable, and secure software through clear responsibility boundaries.

Concise Technical Description

Encapsulation is a central OOP principle that bundles data and behavior into a single unit and restricts direct access to internal representations. Technically, it is implemented through visibility modifiers such as private, protected, public, package, as well as through accessor methods and properties. Information hiding reduces coupling, increases cohesion, and allows implementation changes without affecting consumers. Invariants are maintained within the object, inputs and outputs are validated. Mutability is consciously controlled, immutable objects eliminate entire classes of errors.

Exam-Relevant Key Points

• Information hiding protects internal representation, reduces coupling
• Visibility modifiers private, protected, public, package control access
• Getters and setters are not an end in themselves, only provide when technically necessary
• IHK relevant, clearly distinguish terms encapsulation, abstraction, cohesion, coupling
• Immutable objects increase thread safety and testability in practice
• Validation, invariants, and the Law of Demeter prevent unsafe state manipulation
• Cost-effectiveness through lower maintenance costs and easier refactoring
• Documentation obligation, public interfaces, preconditions, postconditions

Core Components

1. Language elements for visibility, private, protected, public, package
2. Properties and methods, targeted exposure instead of complete disclosure
3. Invariants, business rules that must always apply
4. Contracts, preconditions and postconditions on the public API
5. Mutability concept, mutable, immutable, copy on write
6. Access control and validation, check inputs, atomic state changes
7. Process step, refactoring to hide data fields and internal collections
8. Architecture element, module boundaries, package boundaries, bounded contexts
9. Security aspect, minimizing attack surface and injection points
10. Test procedure, black box tests of the API and property-based tests for invariants

Practical Example

// Example, Java-like syntax
class BankAccount {
private String iban
private int balanceInCents

public BankAccount(String iban) {
if (iban == null) throw new IllegalArgumentException("IBAN required")
this.iban = iban
this.balanceInCents = 0
}

public int balance() {
return balanceInCents
}

public void deposit(int cents) {
if (cents <= 0) throw new IllegalArgumentException("positive amount")
balanceInCents += cents
}

public void withdraw(int cents) {
if (cents <= 0) throw new IllegalArgumentException("positive amount")
if (cents > balanceInCents) throw new IllegalStateException("overdraft not allowed")
balanceInCents -= cents
}
}

Explanation: Fields are private, only technically meaningful operations are public, invariants are checked.

Advantages and Disadvantages

Advantages

• Lower coupling, higher cohesion
• Better maintainability, easier parallelization
• Clear responsibilities, improved security through input controls

Disadvantages

• Possible overhead through boilerplate
• Overly strong encapsulation can hinder testability
• Excessive getter/setter inflation can undermine encapsulation

Typical Exam Questions (with Brief Answers)

1. Difference between encapsulation and abstraction? Encapsulation hides implementation details behind an interface, abstraction reduces visible complexity to relevant properties.

2. Visibility levels and usage? private only within the class, package only within the package, protected class and subclasses, public globally visible.

3. Public fields problematic? They bypass validation, violate invariants, increase coupling, and make refactoring risky.

4. Getters and setters worthwhile? When technical necessity exists, such as read access or controlled change with validation, otherwise avoid.

5. Immutability supports encapsulation? Immutable objects guarantee stable invariants, simplify concurrent use, and prevent side effects.

6. Law of Demeter and how it helps? Talk only to your direct neighbors, no chained access, reduces knowledge of internal structures, strengthens encapsulation.

7. Impact on test strategies? Focus on black box tests of the public API, internal details are verified through observable behavior.

8. Break encapsulation through collections? Returning an internal list enables external mutation, solution, defensive copy or unmodifiable view.

Most Important Sources

1. https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html
2. https://de.wikipedia.org/wiki/Kapselung_(Programmierung)
3. https://dl.acm.org/doi/10.1145/361598.361623