Adapter

1. Adapter

2. A common problem… Our Software External Library Adapter RHS – SOC

3. A common problem… • We often need to fit our own, modifiable, code to a third-party, ”fixed”, library • How do we avoid being bound too tightly to the third-party library…? • The Adapter Pattern is a solution to this – very common - problem RHS – SOC

4. The Adapter pattern • Example: • Our software uses a special external library for e.g. 2-D graphic • The library has an interface, and our code uses that interface directly • Now a better graphics library becomes available, but with a different interface • Rewrite all our code to fit the new library…? RHS – SOC

5. The Adapter pattern Our code Current library RHS – SOC

6. The Adapter pattern • This pattern applies a very general principle – adding a layer of indirection • We wish to avoid a hard ”binding” of our code to a specific library interface • The solution: Insert an extra class between our own code and the library • This class is the Adapter class RHS – SOC

7. The Adapter pattern • The Adapter class gives us a ”virtual” interface that we can define freely! • We can make an interface to a 2-D graphics library which suits us perfectly • A specific Adapter class must ”map” the interface to a specific library • We thus need both an interface class, plus a number of implementations RHS – SOC

8. The Adapter pattern GraphicsInterface drawSquare drawRectangle drawLine … GraphicsAdapterA GraphicsAdapterB drawSquare drawRectangle drawLine … drawSquare drawRectangle drawLine … RHS – SOC

9. The Adapter pattern Our code Graphics Adapter A Library A RHS – SOC

10. The Adapter pattern This stays the same!! Our code Graphics Adapter B Library B RHS – SOC

11. The Adapter pattern Our code Graphics Interface Only this changes!! Graphics Adapter A Graphics Adapter B Library A Library B RHS – SOC

12. Inside the Adapter • We still have work to do; we need to write the code inside each specific adapter • For each adapter, implement the methods in the adapter interface, using the methods available in the adapted library RHS – SOC

13. Inside the Adapter GraphicsInterface drawSquare drawRectangle drawLine … GraphicsAdapterA GraphicsLibraryA drawSquare drawRectangle drawLine … drawLine RHS – SOC

14. Inside the Adapter public void drawLine(int xs, int ys, int xe, int ye) { theLibrary.drawLine(xs, ys, xe, ye); } public void drawSquare(int xs, int ys, int sideLength) { int xe = xs + sideLength; int ye = ys + sideLength; theLibrary.drawLine(xs, ys, xe, ys); theLibrary.drawLine(xe, ys, xe, ye); theLibrary.drawLine(xe, ye, xs, ye); theLibrary.drawLine(xs, ye, xs, ys); } RHS – SOC

15. Inside the Adapter • Writing the adapter itself might be hard, but we only have to do it once! • What if we cannot implement a method at all (drawCircle(…))? • Only use Adapter pattern if there is a genuine ”risk” for changing libraries RHS – SOC

16. Exercises • Download the NetBeans project AdapterExample from the Website (go to Classes, Week 43) • Examine the code; an interface XMathInterface defines a (small) interface to a hypothetical mathematical library • The class XMathToMathAdapter implements the XMathInterface interface, by using the methods in the existing Math library – this is adaptation in action • A test of the adapter class is found in the class XMathTest • Try out the test, and feel free to try to add some more methods to the XMathInterface interface. The methods must be implemented using the existing methods in the Math library RHS – SOC