Sự khác biệt giữa cây cầu, người trung gian và người bao bọc là gì?


7

Các slide trong khóa học của tôi về kiến ​​trúc phần mềm gợi ý rằng đây là những thuật ngữ riêng biệt, nhưng tôi dường như không thể tìm thấy sự khác biệt. Không phải tất cả trong số họ chỉ dịch giao diện?


3
Tôi nghĩ bạn nên cung cấp thêm một số bối cảnh.
Raphael

2
Đăng chéo vào cùng một lúc để chồng tràn .
jmad

Câu trả lời:


8

Việc nghiên cứu các mẫu đầu tiên rất chú trọng đến "mục đích sử dụng" của một mẫu, hơn và hơn bất kỳ sự khác biệt về cấu trúc nào trong quá trình thực hiện. Sau đó, những người ở giai đoạn trưởng thành kiến ​​trúc nơi họ "làm mẫu vì mẫu là việc bạn làm" đã phát triển từ lâu, thường giải thích chi tiết về lý do tại sao những khác biệt được cho là quan trọng này.

Tuy nhiên, nghiên cứu đã chỉ ra rằng cấu trúc thực sự là tất cả những gì quan trọng, bởi vì sự khác biệt về ngữ nghĩa:

  • không có sự phân biệt chính thức, ngay cả trong việc xử lý toán học của lý thuyết loại
  • không thể thực thi nếu không có sự khác biệt về cú pháp trong việc phát triển các mối quan hệ kiểu (trình biên dịch cần một cái gì đó để thực thi)
  • do đó thay đổi với yêu cầu thay đổi
  • và không nên buộc phải không thay đổi, vì tái sử dụng là điểm của kiến ​​trúc tốt

Rất nhiều cuộc thảo luận lớn về lý do tại sao chiến lược khác với nhà nước lại tỏ ra khá nhọc nhằn, thiếu thuyết phục, không hiệu quả và hơi hài hước khi năm tháng trôi qua.

Đề nghị của tôi là bỏ qua mọi cuộc thảo luận "được sử dụng cho" và hoàn toàn tập trung vào các mối quan hệ kiểu. Nếu bạn làm điều đó, thì bạn sẽ thấy điều đó (tùy thuộc vào định nghĩa cụ thể của bạn về các mẫu này, nhưng khá chuẩn ở đây)

Người hòa giải> Cầu> Bộ chuyển đổi

trong đó quan hệ> nên được đọc là "được thực hiện bằng cách sử dụng". Bộ điều hợp là mối quan hệ chức năng giữa ba hoặc nhiều loại xung quanh trên một cây trừu tượng. Cầu và Người hòa giải là mối quan hệ chức năng giữa bốn hoặc nhiều loại xung quanh hai cây trừu tượng, xác định giao diện giữa các cây trừu tượng. Hòa giải viên thêm vào các mối quan hệ sử dụng khớp nối giữa các nút cụ thể của các cây trừu tượng.

Thông thường, Mediator là một mẫu xấu (antipotype) không mở rộng tốt và khiến ứng dụng trở nên nguyên khối. Nó được sử dụng rất thường xuyên bởi vì mọi người đọc những gì nó làm và đi "oh, tôi cần điều đó" và sử dụng một mẫu becasue, như trên, tốt, các mẫu là "những gì bạn sử dụng". Chúng có thể là một bước trung gian trong khi tách riêng một ứng dụng được ghép nhiều trong quá trình tái cấu trúc, nhưng thông thường nếu bạn đang thực hiện bước đó, việc tách rời hoàn toàn thành Bridge (với một nhà máy) được chỉ định và dễ dàng như vậy.


Theo bạn, mô hình "chuẩn" nào khác cũng là phản mẫu?
Novellizator

Tôi nghĩ rằng một trong những phổ biến nhất để đưa lên là Singleton. Bạn không bao giờ nên ép buộc một ngữ nghĩa đối với các đối tượng của bạn (như chỉ có một trường hợp hiện tại) không cần thiết để ép buộc (chỉ khởi tạo một lần nếu đó là những gì bạn cần). Nó thường được sử dụng để làm cho việc truy cập "dễ dàng", và chỉ gây ô nhiễm không gian toàn cầu và che giấu các mối quan hệ phụ thuộc.
ex0du5

Nhưng cái thực sự khiến tôi không thấy trong GoF, nhưng là một mô hình rất phổ biến trong điện toán: bỏ phiếu. Lần duy nhất đây là mỗi "yêu cầu" là phần cứng được thiết kế tồi. Không bao giờ cần thiết cho việc giám sát phần mềm vẫn tồn tại do thiết kế giao thức kém, sự lười biếng giao diện, v.v. Người ta không bao giờ nên lãng phí thời gian khi không biết bạn sẽ tìm thấy bất cứ điều gì hữu ích và việc bỏ phiếu có độ trễ tích hợp hiếm khi hữu ích trong hình thức này. Độ trễ có thể hữu ích trong việc chuyển đổi các chuyển đổi, nhưng điều đó chỉ xảy ra khi một quá trình chuyển đổi đã được xác định. Chúng ta nên cố gắng để được hướng sự kiện.
ex0du5

Thực sự, mặc dù, tôi nghĩ rằng chúng ta không nên nghĩ theo mô hình trừ khi được công nhận. Các kỹ sư thực sự chỉ nên thiết kế những gì xuất phát từ ngôn ngữ miền của họ. Đó là nơi các loại và quan hệ của họ đến từ. Sau đó, chỉ cần ghi nhớ kiến ​​trúc tốt - những thứ như nguyên tắc Mở / Đóng, tái sử dụng, chứa thay vì kế thừa, kế thừa dành cho các cơ sở giao diện trừu tượng rất sâu (chỉ một cơ sở trừ giao diện đa hình có cấu trúc tự nhiên), các máy trạng thái cho các vòng đời của trạng thái [hướng sự kiện], v.v. Điều đó thúc đẩy việc chọn đúng quan hệ, không phải mẫu.
ex0du5

Bạn có thể chỉ ra nghiên cứu rằng "đã chỉ ra rằng cấu trúc thực sự là vấn đề quan trọng"?
PsiX

6

Nói chung có rất nhiều khái niệm về giao diện trong khoa học máy tính. Có lẽ bạn nên nói rằng bạn đang nói về các mẫu thiết kế. Trong bài viết Wikipedia tương ứng , có một phân loại các mẫu khác nhau để xóa mọi thứ:

  • Mẫu hòa giảihành vi (về giao tiếp giữa các giao diện) và thống nhất một số giao diện, đáng chú ý là cách chúng giao tiếp với nhau giống như một hòa giải viên thực tế.

  • Hai cái còn lại là cấu trúc (thực sự so sánh các giao diện):

    • mẫu trình bao bọc / bộ điều hợp được tập trung vào làm cho giao diện tương thích, ví dụ nếu khách hàng sử dụng các quy ước khác nhau;

    • các mô hình cầu là về tách gì lớp được nghĩa vụ phải làm (trừu tượng) từ cách nó thực sự làm nó (thực hiện). Bằng cách đó bạn có thể sử dụng sự trừu tượng mà không cần biết cách triển khai, điều này rất hữu ích khi mã thay đổi (cho cả hai bên).


5

Có sự khác biệt. Hầu hết trong số chúng đủ tinh tế mà bạn sẽ không quan tâm, nhưng chúng thường khác nhau về ý định hoặc cách thực hiện. Ý tưởng bao trùm là cung cấp cho lớp A quyền truy cập vào chức năng của lớp B, mà không cần phải quan tâm rằng đó là B đang thực hiện công việc (để lớp C có thể được thay thế mà không có bất kỳ đối tượng nào trong số này phải thay đổi). Ý tưởng này thường được gọi là "khớp nối lỏng lẻo" và thường được khuyến khích ..

  • Cầu A là định nghĩa cơ bản nhất về ý định tách rời A và B; rằng, trong và của chính nó, là mục đích. A thay vì biết về giao diện I, mà B thực hiện. Một lớp C cũng có thể thực hiện I và có thể được thay thế tự do.

  • Một "trình bao bọc" hoặc Bộ điều hợp thường được viết với mục đích thay đổi giao diện của B để phù hợp với bộ chức năng mà A mong đợi về sự phụ thuộc của nó I. Nếu A mong đợi tôi có phương thức "Do This ()" với ba tham số, nhưng phương thức có chức năng A cần trên B thực sự được đặt tên là "DoThat ()" và lấy tham số, Bộ điều hợp W có thể được viết phụ thuộc vào B (hoặc giao diện B của IB), thực hiện I và gọi B.DoThat () từ phương thức Do This () của chính nó (truyền tham số mà nó có thể đạt được mà không cần kiến ​​thức của A). Nếu C là cần thiết thay thế và khác với B, một Bộ chuyển đổi W2 khác có thể được viết bằng C và cũng thực hiện I, do đó A, W, I, B và C không phải thay đổi.

  • Các mẫu hòa giải về cơ bản là một Bộ chuyển đổi được sử dụng làm Cầu nối. Người hòa giải là đối tượng riêng của mình M, biết về B và được trao cho A. Khi A gọi các phương thức trên M, các cuộc gọi đó được chuyển qua B. M có thể thực hiện các việc bổ sung, như cung cấp liên lạc hai chiều giữa A và B . B có thể được yêu cầu thay đổi dữ liệu của A hoặc gọi các thành viên của mình, nhưng không thể biết về chính A. M có thể giải quyết cấu trúc phụ thuộc "vòng tròn" hoặc "nhiều đến nhiều" này bằng cách cho phép cả A và B phụ thuộc vào M.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.