Adapter Pattern

Mấy năm gần đây, Apple loại bỏ jack tai nghe rồi, chắc mọi người cũng biết. Vậy mọi người có biết nếu ko có jack tai nghe, thì làm sao để nghe được bằng tai nghe có dây bình thường không? Rất đơn giản, người ta chế ra 1 cục chuyển đổi từ đầu cắm jack tai nghe thành đầu sạc iphone, và cái cục này có thể gọi nó là Adapter.
Trong design pattern, chúng ta cũng có 1 khái niệm tương tự. Chúng ta có 1 đoạn class A, muốn xài 1 method x của class B. Nhưng vì lí do nào đó, A không thể xài B được.

Thì chúng ta sẽ tạo ra 1 adapter trung gian là class C. Và nhờ vào class C, A có thể xài được B.

Adapter Pattern: cho ta 1 lớp có thể xài 1 class khác dựa vào interface của nó

Vấn đề ở đây là, tại sao lại có chuyện A không thể xài B được? Chỉ cần khởi tạo B trong A và xài thôi, có gì khó khăn đâu?
Nhưng nếu bạn làm dự án thực tế, bạn sẽ gặp phải những trường hợp mà bạn ko có quyền sửa code. Tức là project của bạn có xài class A, nhưng bạn không có quyền sửa code của A. Lí do là vì, A có thể là thư viện có sẵn, hoặc A có thể là code của một nhóm khác lập trình....
Pattern này quá đơn giản, nên mình sẽ đi vào code luôn.

public class A {
   private ICanUse canUseInterface;
   public A (ICanUse canUseInterface) {
      this.canUseInterface = canUseInterface;
   }
   private void doSomething() {
      this.canUseInterface.request();
   } 
}

Đầu tiên, ta thấy ở trên, ta có class A đã được lập trình sẵn là xài hàm request của ICanUse. Nhưng bây giờ ta lại muốn A xài được hàm specificRequest của interface B dưới đây.

public Interface B {   
   public void specificRequest();
}
public class randomB implements B {
   public void specificRequest() {
      //do something 
   }
}

Để làm được điều này, ta tạo 1 cái Adapter

public class Adapter implements ICanUse {   
   private B b;
   public A (B b) {
      this.b = b;
   }
   public void request() {
       b.specificRequest();
   }
}

Vậy thôi, giờ muốn A có thể xài được specificRequest của B thì chỉ cần.

A a = new A(new Adapter(new B()));
a.request();