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

Abstraction in OOP: Fundamentals Explained

Learn abstraction in OOP: interfaces, abstract classes, composition, Open Closed Principle, contracts, and design patterns.

S

schutzgeist

3 min read
Abstraction in OOP: Fundamentals Explained

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

This article defines abstraction in object-oriented programming, complete with exam questions and key concepts.

In a Nutshell

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

Core Definition

Abstraction is the deliberate elimination of unnecessary details to create a clear, stable model. In OOP, it’s realized through interfaces, abstract classes, role models, and contracts that specify observable behavior. Good abstractions are minimal yet complete, consistently named, orthogonal, and support substitutability while testing well via black-box techniques. Abstraction works closely with encapsulation and polymorphism: abstraction determines what’s visible, encapsulation protects implementation details, and polymorphism enables interchangeable implementations.

Key Exam Topics

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

Core Components

  1. Domain model, ubiquitous language, concepts, and relationships
  2. Contract interface, signatures, semantics, and failure cases
  3. Abstract base classes, shared core logic without complete implementation
  4. Roles, multiple small interfaces instead of one god interface
  5. Composition, has-a relationships for structuring behavior
  6. Generic types, parametric abstraction over types
  7. Design patterns: Strategy, Template Method, Adapter, Ports and Adapters
  8. Architecture boundaries, ports, adapters, and bounded contexts
  9. Quality rules, high cohesion, low coupling, Liskov Substitution Principle compliance
  10. Testing approaches, contract tests, substitution tests, and 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, delimiters, 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

  • Lower coupling, higher cohesion
  • Better testability, clear responsibilities
  • Easy extensibility, more stable APIs

Weaknesses

  • Initial modeling effort
  • Risk of over-abstracted contracts
  • Extra indirection if poorly scoped

Common Exam Questions (with Brief Answers)

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

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

  3. Does it support the Open Closed Principle? Contracts remain stable, new variants emerge as fresh implementations, and existing code needs no changes.

  4. What makes a good abstraction? Minimal but complete, consistently named, orthogonal, stable under internal changes, and clearly documented.

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

  6. What’s an example of bad abstraction? A god interface with many unrelated methods violates ISP, complicates substitutability, and makes testing harder.

  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 interchangeable implementations that bind at runtime via dynamic dispatch.

Key References

  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