liveBook · Manning

Wrapper

As explained in Simple Object-Oriented Design: Create clean, maintainable applications

A wrapper class is a class that groups or adapts other components behind a simpler interface.

A wrapper groups or adapts components behind an interface you control. Its purpose is not to erase every dependency, but to confine dependencies that would otherwise spread through domain code. When an external API changes, the conversion and API-specific calls can usually be updated at that boundary instead of across the system. section 6.3 section 6.6

Use a wrapper when it gives a meaningful domain interface or reduces direct client coupling. A payment gateway wrapper can accept application-owned payment data and translate it to the provider’s PaymentDetails and calls. Similarly, a reporting adapter can accept report data without exposing an Excel library to the rest of the application. section 6.3 section 6.3.1

Grouping dependencies with MessageBot

If MessageSender directly needs both Bot and UserDirectory, introduce MessageBot with a single send(Message) operation. MessageBot obtains the user ID and invokes the bot, so MessageSender depends on one domain-named collaborator rather than two lower-level services. The lower-level dependencies still exist indirectly, but changes to their usage are less likely to affect MessageSender. section 4.3.1

Figure 6.4 The adapter prevents the library code from getting spread into the domain.

The diagram shows the intended boundary: domain code uses the adapter, while the adapter contains the payment-library dependency. section 6.3

Apply wrappers selectively:

  • Keep third-party data structures and SDK calls from becoming default types throughout domain code. section 6.3
  • Prefer a wrapper that expresses a domain responsibility, rather than an extra layer that merely repeats a stable framework API. section 4.2.1 section 6.3.1
  • Accept that wrappers add classes and indirect coupling; use them where change isolation outweighs that cost. section 4.2.1 section 4.3.1

Do not treat wrappers as a mandate to make a system framework-independent. Chosen frameworks and infrastructure can be used fully while their code is kept in appropriate boundaries, such as repositories, data-access objects, or adapters. The practical decision is which external coupling is acceptable and which needs containment. section 4.2.1 section 6.3.1

How Simple Object-Oriented Design: Create clean, maintainable applications covers it

How deep it goes
Explains wrapper boundaries, conversion, dependency grouping, benefits, and tradeoffs without prescribing a universal abstraction scheme.
Examples
Uses a payment gateway adapter, report generation adapter, AWS integration boundary, and MessageBot grouping Bot with UserDirectory.
What you can do after
Apply it by creating domain-focused boundaries that localize external-library changes and simplify direct dependencies.
How it connects
Connects wrappers with adapters, dependency coupling, domain code, third-party libraries, frameworks, repositories, and data access objects.

Also explained in

Compare how 4 books explain wrapper →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Simple Object-Oriented Design: Create clean, maintainable applications. The section links point to the parts of the book it draws on.