Mẫu thiết kế cầu

CHÀO! Bây giờ chúng ta tiếp tục đi sâu vào một chủ đề hữu ích rộng lớn và cực kỳ quan trọng: các mẫu thiết kế. Hôm nay chúng ta hãy nói về mô hình cây cầu. Giống như các mẫu khác, mẫu cầu dùng để giải quyết các vấn đề điển hình mà nhà phát triển gặp phải khi thiết kế kiến ​​trúc phần mềm. Hôm nay chúng ta cùng tìm hiểu đặc điểm của pattern này và tìm hiểu cách sử dụng nó nhé.

Mô hình cây cầu là gì?

Mẫu cầu là một mẫu thiết kế cấu trúc. Nói cách khác, công việc chính của nó là tạo ra một cấu trúc chính thức từ các lớp và đối tượng. Cầu nối thực hiện điều này bằng cách chia một hoặc nhiều lớp thành các phân cấp riêng biệt: trừu tượng hóa và triển khai . Một thay đổi về chức năng trong một hệ thống phân cấp không kéo theo sự thay đổi trong hệ thống phân cấp khác. Đó là tất cả tốt và tốt, nhưng định nghĩa này rất rộng và không trả lời câu hỏi quan trọng nhất: "mẫu cầu là gì?" Tôi nghĩ bạn sẽ dễ hiểu ứng dụng thực tế của nó hơn. Vì vậy, ngay bây giờ, hãy tạo một kịch bản cổ điển cho mô hình cây cầu. Chúng tôi có một Shapelớp trừu tượng, đại diện cho một hình hình học chung:

• Hình dạng.java

  
  public abstract class Shape {
     public abstract void draw();
  }
  

  Khi chúng tôi quyết định thêm các hình dạng như hình tam giác và hình chữ nhật, chúng tôi sẽ làm cho chúng kế thừa Shapelớp:

• Hình chữ nhật.java:

  
  public class Rectangle extends Shape {
     @Override
     public void draw() {
         System.out.println("Drawing rectangle");
     }
  }
  

• Tam giác.java:

  
  public class Triangle extends Shape {
     @Override
     public void draw() {
         System.out.println("Drawing triangle");
     }
  }
  

Mọi thứ có vẻ đơn giản cho đến thời điểm chúng tôi giới thiệu khái niệm về màu sắc. Đó là, mỗi hình dạng sẽ có màu riêng và chức năng của draw()phương thức sẽ phụ thuộc vào màu này. Để có các triển khai khác nhau của draw()phương thức, thì chúng ta cần tạo một lớp cho từng kết hợp màu sắc hình dạng. Nếu chúng ta có ba màu, thì chúng ta cần sáu lớp: TriangleBlack, TriangleGreen, TriangleRed, RectangleBlack, RectangleGreenvà RectangleRed. Sáu lớp không phải là một vấn đề lớn. Nhưng! Nếu chúng ta cần thêm một hình dạng hoặc màu sắc mới, thì số lượng các lớp sẽ tăng theo cấp số nhân. Làm thế nào để thoát khỏi tình trạng này? Lưu trữ màu trong một trường và liệt kê tất cả các tùy chọn bằng câu lệnh điều kiện không phải là giải pháp tốt nhất. Một giải pháp tốt là chuyển màu sang một giao diện riêng. Nói sớm hơn làm: hãy tạo một giao diện Colorvới ba triển khai: BlackColorvà : GreenColorRedColor

• Màu.java:

  
  public interface Color {
     void fillColor();
  }
  

• Màu đen.java:

  
  public class BlackColor implements Color {
     @Override
     public void fillColor() {
         System.out.println("Filling in black color");
     }
  }
  

• GreenColor.java

  
  public class GreenColor implements Color {
     @Override
     public void fillColor() {
         System.out.println("Filling in green color");
     }
  }
  

• RedColor.java

  
  public class RedColor implements Color {
     @Override
     public void fillColor() {
         System.out.println("Filling in red color");
     }
  }
  

  Bây giờ chúng ta thêm một Colortrường vào Shapelớp. Chúng ta sẽ lấy giá trị của nó trong hàm tạo.

• Hình dạng.java:

  
  public abstract class Shape {
     protected Color color;
    
     public Shape(Color color) {
         this.color = color;
     }
  
     public abstract void draw();
  }
  

  Chúng tôi sẽ sử dụng colorbiến trong Shapetriển khai. Điều này có nghĩa là các hình có thể sử dụng chức năng của Colorgiao diện.

• Hình chữ nhật.java

  
  public class Rectangle extends Shape {
  
     public Rectangle(Color color) {
         super(color);
     }
  
     @Override
     public void draw() {
         System.out.println("Drawing rectangle");
         color.fillColor();
     }
  }
  

Ta-da! Bây giờ chúng ta có thể tạo ra các màu sắc và hình dạng khác nhau đến vô hạn, và số lượng các lớp sẽ chỉ tăng tuyến tính. Trường này Color colorlà cầu nối kết nối hai hệ thống phân cấp lớp riêng biệt.

Cách xây dựng một cây cầu: trừu tượng hóa và triển khai

Hãy xem một sơ đồ lớp mô tả mẫu cầu nối: Ở đây bạn có thể thấy hai cấu trúc độc lập có thể được sửa đổi mà không ảnh hưởng đến chức năng của nhau. Trong trường hợp của chúng ta:

• Trừu tượng là Shapelớp
• RefinedAbstraction là Trianglevà Rectanglecác lớp
• Người thực hiện là Colorgiao diện
• ConcreteImplementor là BlackColorvà GreenColorcác RedColorlớp.

Lớp Shapelà một sự trừu tượng - một cơ chế để quản lý việc lấp đầy các hình dạng với nhiều màu sắc khác nhau, ủy quyền cho giao Colordiện (Người triển khai). Các lớp Trianglevà Rectanglelà các lớp cụ thể sử dụng cơ chế do lớp cung cấp Shape. BlackColorvà GreenColorlà RedColorcác triển khai cụ thể trong hệ thống phân cấp Triển khai.

Trường hợp sử dụng mẫu cầu

Một lợi ích to lớn của việc sử dụng mẫu này là bạn có thể thực hiện các thay đổi đối với các lớp chức năng trong một hệ thống phân cấp mà không vi phạm logic của hệ thống kia. Ngoài ra, cách tiếp cận này giúp giảm sự ghép nối giữa các lớp. Yêu cầu chính khi sử dụng mẫu này là "làm theo hướng dẫn" — đừng bỏ qua bất kỳ hướng dẫn nào! Để làm được điều đó, hãy tìm hiểu các tình huống khi bạn chắc chắn nên sử dụng mẫu cầu nối:

1. Nếu bạn cần mở rộng số lượng thực thể dựa trên sự kết hợp của hai khái niệm (ví dụ: hình dạng và màu sắc).

2. Nếu bạn muốn chia một lớp lớn không đáp ứng nguyên tắc một trách nhiệm thành các lớp nhỏ hơn có chức năng hẹp.

3. Nếu cần thay đổi logic của các thực thể nhất định trong khi chương trình đang chạy.

4. Nếu cần ẩn một triển khai khỏi các máy khách của lớp hoặc thư viện.

Khi bạn sử dụng mẫu này, hãy luôn nhớ rằng nó thêm các thực thể bổ sung vào mã của bạn — sẽ không hợp lý nếu sử dụng nó trong một dự án chỉ có một hình dạng và một hoặc hai màu có thể có.

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

Giống như các mô hình khác, một cây cầu có cả ưu điểm và nhược điểm. Ưu điểm của mô hình cây cầu:

1. Nó cải thiện khả năng mở rộng của mã — bạn có thể thêm chức năng mà không sợ làm hỏng thứ gì đó trong phần khác của chương trình.
2. Nó làm giảm số lượng các lớp con khi số lượng thực thể dựa trên sự kết hợp của hai khái niệm (ví dụ: hình dạng và màu sắc).
3. Nó cho phép làm việc riêng biệt trên hai hệ thống phân cấp riêng biệt - Trừu tượng hóa và Thực hiện. Hai nhà phát triển khác nhau có thể thực hiện các thay đổi mà không cần đi sâu vào chi tiết mã của nhau.
4. Nó làm giảm sự ghép nối giữa các lớp — nơi duy nhất mà hai lớp được ghép nối là cầu nối (tức là trường Color color).

Nhược điểm của mô hình cây cầu:

1. Tùy thuộc vào tình huống cụ thể và cấu trúc tổng thể của dự án, nó có thể tác động tiêu cực đến hiệu suất của chương trình (ví dụ: nếu bạn cần khởi tạo nhiều đối tượng hơn).
2. Nó làm cho mã khó đọc hơn do phải chuyển đổi giữa hai lớp.

Sự khác biệt từ mô hình chiến lược

Mẫu cầu thường bị nhầm lẫn với một mẫu thiết kế khác - chiến lược. Cả hai đều sử dụng bố cục (mặc dù chúng tôi đã sử dụng tổng hợp trong ví dụ với số liệu và màu sắc, mẫu Cầu cũng có thể sử dụng bố cục), ủy thác công việc cho các đối tượng khác. Nhưng có một sự khác biệt giữa chúng, và nó rất lớn. Mẫu chiến lược là một mẫu hành vi: nó giải quyết các vấn đề hoàn toàn khác nhau. Chiến lược cho phép các thuật toán được hoán đổi cho nhau, trong khi cầu nối tách biệt một phần trừu tượng khỏi các triển khai để lựa chọn giữa các triển khai khác nhau. Nói cách khác, không giống như một chiến lược, một cây cầu áp dụng cho toàn bộ thực thể hoặc cấu trúc phân cấp. Mẫu cây cầu có thể là một vũ khí tốt trong kho vũ khí của nhà phát triển. Điều chính là xác định các tình huống đáng để sử dụng nó và nhận ra khi nào một số mẫu khác phù hợp.

• Độc thân
• Nhà máy
• nhà máy trừu tượng
• phương pháp xuất xưởng
• Ủy quyền
• bộ chuyển đổi