𝐓𝐢𝐭𝐥𝐞🔌𝐀𝐝𝐚𝐩𝐭𝐞𝐫 𝐃𝐞𝐬𝐢𝐠𝐧 𝐏𝐚𝐭𝐭𝐞𝐫𝐧

⁉️ 𝐈𝐧𝐭𝐞𝐧𝐭
Allows classes work together although they have incompatible interfaces.

🤯𝐏𝐫𝐨𝐛𝐥𝐞𝐦
Have you ever tried to integrate two existing system…but they just don’t fit together?

🌏 𝐑𝐞𝐚𝐥-𝐖𝐨𝐫𝐥𝐝 𝐒𝐜𝐞𝐧𝐚𝐫𝐢𝐨
For example a drawing editor provides users actions such as: draw and arrange of graphical elements (lines, text, etc.). This editor provides an abstract class named Shape. Classes for elementary shapes like LineShape and PolygonShape are easy to implement, but TextShape is not because it displays and edits text. Meanwhile, there is a toolkit class which already implements displaying and editing text named TextView, but it was not designed to work with Shape classes. Therefore, we cannot use TextView and Shape interchangeably. How can we cope with this issue?

🎯 𝐒𝐨𝐥𝐮𝐭𝐢𝐨𝐧 — 𝐀𝐝𝐚𝐩𝐭𝐞𝐫 𝐏𝐚𝐭𝐭𝐞𝐫𝐧
We can define TextShape so that it adapts the TextView to Shape. We can do it in one of two ways:
1️⃣𝐈𝐧𝐡𝐞𝐫𝐢𝐭𝐚𝐧𝐜𝐞
2️⃣𝐂𝐨𝐦𝐩𝐨𝐬𝐢𝐭𝐢𝐨𝐧

💎𝐑𝐞𝐥𝐚𝐭𝐞𝐝 𝐏𝐚𝐭𝐭𝐞𝐫𝐧𝐬
Bridge has a structure similar to an object adapter, but Bridge has a different intent: It is meant to separate an interface from its implementation so that they can be varied independently. An Adapter is meant to change the interface of an existing object. Decorator enhances another object without changing its interface. A decorator is thus more transparent to the application than an adapter is. As a consequence, Decorator supports recursive composition, which isn't possible with pure adapters.

📂 𝐂𝐨𝐝𝐞 𝐄𝐱𝐚𝐦𝐩𝐥𝐞
See it in action:
👉 GitHub - (https://github.com/shirin-monzavi/AdapterSample)

❓𝐖𝐡𝐢𝐜𝐡 𝐝𝐞𝐬𝐢𝐠𝐧 𝐩𝐚𝐭𝐭𝐞𝐫𝐧 𝐝𝐨 𝐲𝐨𝐮 𝐬𝐭𝐫𝐮𝐠𝐠𝐥𝐞 𝐰𝐢𝐭𝐡 𝐭𝐡𝐞 𝐦𝐨𝐬𝐭?

👇 I’d love to hear your thoughts!