The Adapter pattern integrates code that was never designed to work together. It translates an unchangeable adaptee’s interface into the target interface expected by existing clients, while isolating external interface changes. section 10.0 section 10.1
Refactoring exposes why the pattern helps:
- Before: AttendanceReport handles separate printing methods and converts each sport’s data itself, creating duplication and coupling to data representations. section 10.1
- After: FootballData and VolleyballData implement GameData, wrap their legacy objects, and convert each representation through report_venue() and report_attendance(). section 10.1.3
- AttendanceReport now prints through one GameData interface and no longer knows how football or volleyball data is stored. section 10.1.3
Sports attendance reporting
BaseballData already satisfies GameData. FootballInfo stores values in a list, while VolleyballStats stores them in a dictionary. FootballData and VolleyballData translate those structures so one AttendanceReport can print all three sports uniformly. section 10.1
The common object adapter uses composition: an adapter implements the target interface and wraps an adaptee. A class adapter instead uses multiple inheritance. Choose composition when adapters should be shared or should also wrap adaptee subclasses; choose inheritance when clients should hide the adaptee or override its methods. section 10.1.4 section 10.1.5
Figure 10.3 The generic model of the Adapter Design Pattern. Compare with figure 10.2. The Adapter class implements the Target interface. It adapts an Adaptee class by wrapping it so that the latter can work with the Target interface.
Use the generic model to map a target interface, adapter, and adaptee onto a concrete integration design. section 10.1.4
