1 số bài toán ứng dụng adapter pattern năm 2024

Đúng là như vậy nhưng khi đi vào lĩnh vực lập trình và cụ thể ở đây là Design Pattern thì Adapter có nghĩ là bộ chuyển đổi trung gian.

• Định nghĩ về Adapter Pattern: – Adapter Pattern là pattern giữ vai trò trung gian giữa hai lớp, chuyển đổi giao diện của một hay nhiều lớp có sẵn thành một giao diện khác, thích hợp cho lớp đang viết. Điều này giúp các lớp có interface không tương thích có thể làm việc với nhau. – Adapter còn có tên gọi khác là Wrapper – Adapter thuộc nhóm cấu trúc mẫu Structural Pattern
• Vậy mục đích sử dụng của Adapter Pattern là gì? – Chuyển đổi interface có sẵn thành một interface khác thích hợp cho class hiện tại – Tái sử dụng lại interface có sẵn để giảm thiểu việc viết lại code vẫn đảm bảo yêu cầu – Xây dựng, mở rộng các phương thức của lớp có sẵn để phù hợp với yêu cầu
• Các thành phần tham gia vào mẫu thiết kế Adapter:
  – Client: Đây là lớp sẽ sử dụng đối tượng của bạn (đối tượng mà bạn muốn chuyển đổi giao diện). – Adaptee: Đây là những lớp bạn muốn lớp Client sử dụng, nhưng hiện thời giao diện của nó không phù hợp. – Adapter: Đây là lớp trung gian, thực hiện việc chuyển đổi giao diện cho Adaptee và kết nối Adaptee với Client. – Target: định nghĩa giao diện đang làm việc (domain specific).
• Cách thức hoạt động của Adapter Pattern: Định nghĩa một lớp Adapter riêng biệt chuyển đổi interface (không tương thích) của một lớp (Adaptee) thành một interface (Target) yêu cầu => Thông qua Adapter để làm việc với các lớp (tái sử dụng) mà không cần có interface yêu cầu.
• Phân loại Adapter Pattern:
  Object Adapter Pattern Class Adapter Pattern Để một Adapter đơn lẻ làm việc với nhiều Adaptee ( có thể là chính adaptee đó hoặc tất cả lớp con của adaptee đó) Chuyển đổi Adaptee sang Target bằng việc ủy thác tới các lớp Adapter cụ thể. Như một hệ quả, một lớp sẽ không làm việc khi chúng ta muốn chuyển đổi một lớp và tất cả lớp con của nó. Khó khăn hơn trong việc override các hành vi của Adapee, nó cũng yêu cầu lớp con Adaptee và để cho Adapter hướng đến các lớp con thay vì chính Adaptee Dễ dàng để Adapter override hành vi của Adaptee vì Adapter là lớp con của Adaptee Adapter có thể thêm chức năng tới tất cả các Adaptee cùng một lúc Chỉ cho phép một đối tượng và không cần thêm một con trỏ nào khác để chuyển đến Adaptee
• Lĩnh vực áp dụng của mẫu thiết kế: – Một hệ thống lớn luôn luôn sử dụng, kết nối đến các thư viện bên ngoài hoặc API, vì thế chúng ta nên áp dụng Adapter Pattern cài đặt các method adapter. Áp dụng tốt pattern này sẽ giúp hệ thống không xảy ra xự cố khi mà API hay bên thứ ba có sự thay đổi code – Sử dụng khi code của bạn phải phụ thuộc vào class khác mà có sự thay đổi một cách thường xuyên trong class đó để đáp ứng yêu cầu đặt ra.
• Vậy ưu nhược điểm của mẫu Adapter Pattern so với mẫu khác là gì?
  • Ưu điểm: – Linh động trong việc chuyển đổi các giao diện- Nếu chương trình hiện tại không thể thêm trực tiếp module thì có thể sử dụng mẫu để chuyển đổi thêm gián tiếp – Mẫu sử dụng phổ biến trong việc vận hành các API, thư viện bên ngoài
  • Nhược điểm: – Cần nhiều sự kết hợp từ lớp Client, Adapter, Adaptee cho việc chuyển đổi giao diện trên 1 module nào đó
• Các vấn đề đặt ra của mẫu Adapter Pattern:
  • Adapter có thể điều chỉnh bao nhiêu chuyển đổi?
  • Pluggable adapters
  • Sử dụng Adapter hai chiều cho việc sử dụng xuyên suốt chương trình
• Các mẫu thiết kế có liên quan với Adapter Pattern:
  • Bridge
  • Decorator
  • Proxy

Hai phần cuối là các vấn đề đặt ra của mẫu và các mẫu thiết kế liên quan với Adapter Pattern khá phức tạp khó hiểu nên mình sẽ trình bày trong bài viết tiếp theo. Phần 2 mình cũng sẽ đi vào demo ví dụ cho các bạn luôn nên mình mong phần lý thuyết này các bạn nắm chắc để cùng qua phần 2 thực hành nhé. Cảm ơn các bạn đã đọc và theo dõi bài viết dựa trên bài thuyết trình của nhóm mình và dựa trên Ebook: Design Patterns – Elements of Reusable Object-Oriented Software . Các bạn cùng đón chờ phần 2 về Adapter Pattern nhé!

Adapter là một mẫu thiết kế cấu trúc cho phép các đối tượng có giao diện không tương thích có thể tương tác nhau.

Đặt vấn đề

Hãy tưởng tượng rằng bạn đang viết một ứng dụng theo dõi thị trường chứng khoán. Ứng dụng tải dữ liệu từ nhiều nguồn ở định dạng XML, sau đó hiển thị các biểu đồ và sơ đồ đẹp mắt cho người dùng.

Tại một thời điểm, bạn quyết định cải thiện ứng dụng bằng cách tích hợp thư viện phân tích thông minh của bên thứ 3. Nhưng có một điểm lưu ý, thư viện chỉ hoạt động với dữ liệu ở định dạng JSON.

Bạn không thể sử dụng “nguyên trạng” thư viện phân tích vì nó yêu cầu dữ liệu ở định dạng không tương thích với ứng dụng của bạn.

Bạn có thể thay đổi thư viện để làm việc với XML. Tuy nhiên, điều này có thể phá vỡ một số mã hiện có của thư viện. Và tệ hơn, bạn có thể không có quyền truy cập vào mã nguồn của thư viện ngay từ đầu, khiến cho phương pháp này không thể thực hiện được.

Giải pháp

Bạn có thể tạo một adapter. Đây là một đối tượng đặc biệt chuyển đổi giao diện của một đối tượng để đối tượng khác có thể hiểu được nó.

Adapter bao bọc một trong các đối tượng để che giấu sự phức tạp của quá trình chuyển đổi diễn ra bên trong. Đối tượng được bọc thậm chí không biết về adapter. Ví dụ, bạn có thể bao một đối tượng mà hoạt động theo mét và ki lô mét với một adapter chuyển đổi tất cả các dữ liệu thành các đơn vị feet và mile.

Adapter không chỉ có thể chuyển đổi dữ liệu thành nhiều định dạng khác nhau mà còn có thể giúp các đối tượng có giao diện khác nhau tương tác được. Dưới đây là cách nó hoạt động:

1. Adapter có một giao diện, tương thích với một trong các đối tượng hiện có.
2. Sử dụng giao diện này, đối tượng hiện có có thể gọi các phương thức của adapter một cách an toàn.
3. Khi nhận được lời gọi, adapter sẽ chuyển yêu cầu tới đối tượng thứ hai, nhưng theo định dạng và thứ tự mà đối tượng thứ hai mong đợi.

Đôi khi, thậm chí có thể tạo adapter hai chiều có thể chuyển đổi lời gọi theo cả hai hướng.

Quay lại ứng dụng thị trường chứng khoán của chúng ta. Để giải quyết vấn đề về các định dạng không tương thích, bạn có thể tạo adapter XML sang JSON cho mọi lớp của thư viện phân tích mà chương trình làm việc trực tiếp. Sau đó, điều chỉnh mã để chỉ giao tiếp với thư viện thông qua các adapter này. Khi một adapter nhận được lời gọi, nó sẽ dịch dữ liệu XML đến thành một cấu trúc JSON và chuyển cuộc gọi đến các phương thức thích hợp của một đối tượng phân tích được bao bọc.

Cấu trúc

Object adapter

Việc triển khai này sử dụng nguyên tắc hợp thành đối tượng: adapter thực hiện giao diện của một đối tượng và bao bọc đối tượng khác. Nó có thể được thực hiện trong tất cả các ngôn ngữ lập trình phổ biến.

1. Client là một lớp chứa logic nghiệp vụ hiện có của chương trình.
2. Giao diện Client mô tả một giao thức mà các lớp khác phải tuân theo để có thể cộng tác với client.
3. Service là một số lớp hữu ích (thường là bên thứ 3). Client không thể sử dụng trực tiếp lớp này vì nó có giao diện không tương thích.
4. Adapter là một lớp có thể hoạt động với cả Client và Service, nó triển khai giao diện Client, trong khi bao đối tượng Service. Adapter nhận các lời gọi từ Client thông qua giao diện adapter và chuyển chúng thành các lời gọi đến đối tượng service được bao bọc theo định dạng mà nó có thể hiểu được.
5. Client không được ghép nối với lớp Adapter cụ thể mà nó hoạt động thông qua giao diện Client. Nhờ đó, bạn có thể tạo các kiểu adapter mới cho chương trình mà không phá vỡ client hiện có. Điều này có thể hữu ích khi giao diện của lớp service được thay đổi hoặc thay thế: bạn có thể chỉ cần tạo một lớp adapter mới mà không cần thay đổi client.

Class adapter

Việc triển khai này sử dụng tính kế thừa: adapter kế thừa các giao diện từ cả hai đối tượng cùng một lúc. Lưu ý rằng cách tiếp cận này chỉ có thể được thực hiện trong các ngôn ngữ lập trình hỗ trợ đa kế thừa, chẳng hạn như C++.

Adapter không cần phải bọc bất kỳ đối tượng nào vì nó kế thừa các hành vi từ client và service. Việc điều chỉnh xảy ra trong các phương thức bị ghi đè. Kết quả có thể được sử dụng thay cho một lớp client hiện có.

Khả năng áp dụng

• Sử dụng Adapter khi bạn muốn sử dụng một số lớp hiện có, nhưng giao diện của nó không tương thích với phần còn lại của mã của bạn.
• Sử dụng Adapter khi bạn muốn sử dụng lại một số lớp con hiện có thiếu một số chức năng phổ biến mà không thể thêm vào lớp cha.

Ưu và nhược điểm

😄😄😄

Nguyên tắc Đơn trách nhiệm. Bạn có thể tách giao diện hoặc mã chuyển đổi dữ liệu khỏi logic nghiệp vụ chính của chương trình. Nguyên tắc Mở / Đóng. Bạn có thể tạo các kiểu adapter mới trong chương trình mà không vi phạm mã client hiện có, miễn là chúng hoạt động với adapter thông qua giao diện client.

🙁🙁🙁

Độ phức tạp tổng thể của chương trình tăng lên vì bạn cần tạo một tập hợp các giao diện và lớp mới. Đôi khi, đơn giản hơn chỉ là thay đổi lớp service để nó khớp với phần còn lại của chương trình.

Mối quan hệ với các mẫu khác

Bridge thường được thiết kế up-front, cho phép bạn phát triển các phần của ứng dụng một cách độc lập với nhau. Ngược lại, Adapter thường được sử dụng với một ứng dụng hiện có để làm cho một số lớp không tương thích hoạt động với nhau.

Adapter thay đổi giao diện của một đối tượng hiện có, trong khi Decorator tăng cường chức năng một đối tượng mà không thay đổi giao diện của nó. Ngoài ra, Decorator hỗ trợ đệ quy, điều này không thể thực hiện được khi bạn sử dụng Adapter.

Adapter cung cấp một giao diện khác cho đối tượng được bao bọc, Proxy cung cấp cho nó một giao diện tương tự và Decorator cung cấp cho nó một giao diện tăng cường.

Facade định nghĩa một giao diện mới cho các đối tượng hiện có, trong khi Adapter cố gắng làm cho giao diện hiện có có thể sử dụng được. Adapter thường chỉ bao bọc một đối tượng, trong khi Facade hoạt động với toàn bộ hệ thống con của các đối tượng.

Bridge, State, Strategy (và ở một mức độ nào đó là Adapter) có cấu trúc rất giống nhau. Thật vậy, tất cả các mẫu này đều dựa trên hợp thành, tức là ủy thác công việc cho các đối tượng khác. Tuy nhiên, chúng đều giải quyết các vấn đề khác nhau. Mẫu thiết kế không chỉ là một công thức để cấu trúc chương trình của bạn theo một cách cụ thể. Nó cũng có thể giao tiếp với các nhà phát triển khác về vấn đề mà mẫu giải quyết.