Skip to content
IRC-CodingIRC-Coding
AbstractionOOPInterfaceAbstract ClassCompositionOpen Closed PrincipleContractsDesign by Contract

Abstraction in OOP: Fundamentals Explained

Learn abstraction in OOP: reduce complexity to essential properties using interfaces, abstract classes, composition, and Design by Contract.

S

schutzgeist

3 min read
Abstraction in OOP: Fundamentals Explained

Abstraction in OOP Fundamentals – Interface, Abstract Class, Composition, Open Closed Principle

This article is a conceptual overview of abstraction in OOP, including exam questions and key points.

In a Nutshell

Abstraction reduces complex systems to their essential properties and operations. It defines the what of an interface while hiding the how, allowing implementation to evolve independently.

Core Definition

Abstraction is the deliberate omission of irrelevant details to achieve a clear, stable model. In OOP, it’s implemented through interfaces, abstract classes, role models, and contracts that specify observable behavior. Good abstractions are minimal yet complete, consistently named, orthogonal, and support interchangeability while lending themselves to black-box testing. Abstraction works closely with encapsulation and polymorphism: abstraction determines what’s visible, encapsulation protects implementation details, and polymorphism enables swappable implementations.

Exam-Relevant Key Points

  • Focus on relevant properties; minimize the visible surface area
  • Mechanisms: interfaces, abstract classes, composition, generics
  • Separation of contract from implementation; promotes loose coupling and high cohesion
  • IHK-relevant; distinguish precisely from encapsulation and inheritance
  • Best practice: small, role-based interfaces following the Interface Segregation Principle
  • Security aspect: clear contracts limit the attack surface and prevent unvalidated state manipulation
  • Business value: stable contracts reduce maintenance and change costs
  • Documentation requirement: explicitly describe preconditions, postconditions, exceptions, and side effects

Core Components

  1. Domain model and ubiquitous language—terms and relationships
  2. Contract interface—signatures, semantics, failure modes
  3. Abstract base classes—shared foundational logic without complete implementation
  4. Roles—multiple small interfaces instead of one God interface
  5. Composition—has-a relationships to structure behavior
  6. Generic types—parametric abstraction across types
  7. Design patterns—Strategy, Template Method, Adapter, Ports and Adapters
  8. Architecture boundaries—Ports, Adapters, Bounded Contexts
  9. Quality rules—high cohesion, low coupling, LSP conformance
  10. Testing approaches—contract tests, substitution tests, property-based tests

Practical Example

// Goal: abstract file export
interface Exporter {
byte[] export(Report r)
}

class PdfExporter implements Exporter {
public byte[] export(Report r) { /* PDF rendering, validation, byte stream */ }
}

class CsvExporter implements Exporter {
public byte[] export(Report r) { /* CSV serialization, delimiting, encoding */ }
}

class ReportService {
private Exporter exporter
public ReportService(Exporter exporter) { this.exporter = exporter }
public byte[] exportReport(Report r) {
if (r == null) throw new IllegalArgumentException("Report required")
return exporter.export(r)
}
}

Explanation: The Exporter interface defines the abstraction for export; concrete formats are interchangeable, and ReportService remains unchanged.

Strengths and Weaknesses

Strengths

  • Reduced coupling, increased cohesion
  • Better testability and clear responsibility boundaries
  • Easier extensibility and more stable APIs

Weaknesses

  • Initial modeling overhead
  • Risk of over-abstracted contracts
  • Added indirection when the abstraction is poorly scoped

Typical Exam Questions (with Brief Answers)

  1. Abstraction vs. Encapsulation? Abstraction defines which relevant aspects are visible; encapsulation hides the implementation of those aspects behind the interface.

  2. Interface vs. Abstract Class? Use interfaces for pure contracts and multiple roles; use abstract classes when sharing common foundational logic or state.

  3. How does this support the Open Closed Principle? Contracts remain stable; new variants emerge as new implementations, and existing code doesn’t need to change.

  4. Criteria for good abstraction? Minimal yet complete, consistently named, orthogonal, stable under internal changes, clearly documented.

  5. How do you assess the quality of an abstraction? Metrics: method count per interface, change frequency, reuse, test coverage, number of implementations.

  6. Example of poor abstraction? A God interface with many unrelated methods violates ISP, undermines interchangeability, and complicates testing.

  7. What role do generics play in abstraction? Parametric abstraction: one algorithm works across many types without casts, with compiler-enforced type safety.

  8. How do polymorphism and abstraction work together? Abstraction defines the contract; polymorphism provides swappable implementations through dynamic dispatch at runtime.

Key Resources

  1. https://docs.oracle.com/javase/tutorial/java/IandI/abstract.html
  2. https://de.wikipedia.org/wiki/Abstraktion_(Informatik)
  3. https://martinfowler.com/bliki/RoleInterface.html
Back to Blog
Share:

Related Posts