Lợi ích của Mẫu Cầu

Question

Khi tôi muốn học cái gì mới, tôi tự hỏi bản thân mình, những gì tôi bị mất khi tôi không học được điều đó. Tôi sẽ học một số mẫu thiết kế và mọi thứ đều tốt. Nhưng khi tôi đến Bridge Design Pattern tôi đã rơi vào vấn đề. Thực sự tôi không thể tưởng tượng khi sử dụng mẫu thiết kế này. Và tôi biết có một liên kết khác trong google và stackoverflow như this.

Nhưng bất cứ ai cũng có thể nói rằng, những gì chúng tôi mất nếu chúng ta quên Bridge Design Pattern và bỏ qua thử mẫu này?

Answer 1

Các mô hình cầu chỉ đơn giản là nhận thấy một vài tụ trách nhiệm và tách chúng. Tôi sẽ sử dụng ví dụ của The Gang of Four (TGF) vì tôi nghĩ nó là một ví dụ thực sự tốt:

Bạn có giao diện cửa sổ, với hai phân lớp: XWindow (dựa trên Trình quản lý cửa sổ X) và PMWindow (dựa trên trên Trình quản lý cửa sổ trình bày (PM) của IBM ... mà tôi chưa từng nghe đến).

ví dụ:

interface Window {} 
class XWindow : Window {} 
class PMWindow : Window {} 

Vấn đề với việc tiếp tục trong cách tiếp cận kế thừa truyền thống của chúng tôi là nếu bạn chuyên Window trên một khía cạnh khác hơn là phụ thuộc nền tảng của nó (ví dụ, bạn có một số trách nhiệm mà là trực giao với một trong những bạn tạo cây thừa kế để hỗ trợ), bạn cần sử dụng mẫu bridge, nếu không hệ đẳng cấp lớp của bạn sẽ phát triển theo chiều sâu về mặt hình học. Tôi nghĩ rằng một cách tốt để nghĩ về cây cầu như là một sự kết hợp của thừa kế và thành phần.

Khá là dài dòng. Quay trở lại ví dụ TGF: nếu bạn muốn một IconWindow và một TransientWindow (một cái gì đó giống như một ngăn kính). Khái niệm "Icon vs Transient" và "PM vs X" là hai ý tưởng trực giao, nhưng cả hai đều cố gắng để có được trên cùng một cây thừa kế. Nếu không sử dụng mẫu cầu, những gì bạn sẽ phải làm là tạo hai giao diện mới kế thừa từ đầu tiên và một loạt các lớp bên dưới chúng:

interface Window {} 
class XWindow : Window {} 
class PMWindow : Window {} 
interface IconWindow : Window {} 
class XIconWindow : XWindow, IconWindow {} 
class PMIconWindow : PMWindow, IconWindow {} 
interface TransientWindow : Window {} 
class XTransientWIndow : XWindow, TransientWindow {} 
class PMTransientWindow : PMWindow, TransientWindow {} 

Với mẫu cầu bạn sẽ tách hai trách nhiệm đối với hai cây thừa kế:

interface Window {} 
class IconWindow : Window {} //this class... 
class TransientWindow : Window {} //and this one will keep a private reference to aWindowImp 
interface WindowImp: Window {} 
class XWindowImp : WindowImp {} 
class PMWindowImp : WindowImp {} 

Phân biệt trách nhiệm rõ ràng hơn, tốt hơn nhiều và dễ dàng hơn để viết và sử dụng!

I tin rằng vấn đề thiết kế này và sự kỳ quặc của cây đối tượng ngay cả thực sự là một số vấn đề thúc đẩy thiết kế Mix-in trong Scala. Sử dụng đa nhiệm thừa kế của C++, bạn sẽ tĩnh vài lần triển khai thực hiện vào hệ thống cửa sổ của họ. Nói cách khác, bạn có cùng số kiểu như mẫu phi cầu nhưng chúng có thể là các lớp trống và bạn có thể tham chiếu đến chúng bằng cách trừu tượng hóa, điều này làm cho nó dễ tiêu thụ.

Answer 2

Ưu điểm của cầu là trừu tượng hóa và triển khai được tách riêng. Việc thực hiện cũng được thay đổi một cách năng động vào thời gian chạy và khả năng mở rộng của việc trừu tượng hóa và triển khai được cải thiện.

Bằng cách chỉ định tham số trong quá trình tạo trừu tượng, việc triển khai cũng có thể được chọn để thực hiện ứng dụng khách hoàn toàn bị ẩn. Có thể tránh được sự gia tăng mạnh về số lượng lớp học.