Façade vs. Mediator


83

Tôi đã nghiên cứu sự khác biệt giữa hai mẫu này.

Tôi hiểu rằng mặt tiền đóng gói quyền truy cập vào hệ thống con và trình trung gian đóng gói các tương tác giữa các thành phần.

Tôi hiểu rằng các thành phần của hệ thống phụ không nhận biết được mặt tiền, trong đó các thành phần hiển nhiên nhận biết về trình trung gian.

Tôi hiện đang sử dụng một mặt tiền để đóng gói phương pháp truy xuất thông tin cấu hình, ví dụ: App.Config, cài đặt người dùng được lưu trữ trong SQL, thông tin Assembly, v.v. và một bộ trung gian để điều hướng giữa các biểu mẫu cửa sổ khác nhau.

Tuy nhiên, hầu hết các trang web đều chỉ ra rằng người dàn xếp “thêm chức năng”. Ý của họ về vấn đề này là như thế nào? Người hòa giải thêm chức năng như thế nào?

Câu trả lời:


103

... hầu hết các trang web chỉ ra rằng trình dàn xếp "thêm chức năng" ...

Các mặt tiền chỉ cho thấy nhiều chức năng hiện có từ một góc độ khác nhau.

Các trung gian "thêm" chức năng vì nó kết hợp chức năng hiện có khác nhau để tạo ra một cái mới.

Lấy ví dụ sau:

Bạn có một hệ thống ghi nhật ký. Từ hệ thống ghi nhật ký đó, bạn có thể đăng nhập vào tệp, vào ổ cắm hoặc vào cơ sở dữ liệu.

Sử dụng mẫu thiết kế mặt tiền, bạn sẽ "ẩn" tất cả các mối quan hệ khỏi chức năng hiện có đằng sau một "giao diện" duy nhất mà mặt tiền lộ ra.

Mã khách hàng:

 Logger logger = new Logger();
 logger.initLogger("someLogger");
 logger.debug("message");

Việc thực hiện có thể liên quan đến sự tương tác của nhiều đối tượng. Nhưng cuối cùng, chức năng đã tồn tại. Có thể phương pháp "gỡ lỗi" được thực hiện như sau:

Thực hiện:

 class Logger { 

      private LoggerImpl internalLogger;
      private LoggerManager manager;

      public void initLogger( String loggerName ) {
          this.internalLogger = manager.getLogger( loggerName ); 
      }

      public void debug( String message ) { 
          this.internalLogger.debug( message );
      }     
 }

Chức năng đã tồn tại. Mặt tiền chỉ che giấu nó. Trong trường hợp giả định này, LoggerManager xử lý việc tạo trình ghi chính xác và LoggerImpl là một đối tượng gói-riêng có phương thức "gỡ lỗi". Bằng cách này, Mặt tiền không thêm chức năng mà chỉ là ủy quyền cho một số đối tượng hiện có.

Mặt khác, trình hòa giải thêm chức năng mới bằng cách kết hợp các đối tượng khác nhau.

Cùng một mã Khách hàng:

 Logger logger = new Logger();
 logger.initLogger("someLogger");
 logger.debug("message");

Thực hiện:

 class Logger { 

      private java.io.PrintStream out;
      private java.net.Socket client;
      private java.sql.Connection dbConnection;
      private String loggerName;


      public void initLogger( String loggerName ) {
               this.loggerName = loggerName;
               if ( loggerName == "someLogger" ) { 
                    out = new PrintStream( new File("app.log"));
               } else if ( loggerName == "serverLog" ) { 
                    client = new Socket("127.0.0.1", 1234 );
               } else if( loggerName == "dblog") { 
                    dbConnection = Class.forName()... .
               }

      }

      public void debug( String message ) { 

               if ( loggerName == "someLogger" ) { 
                    out.println( message );
               } else if ( loggerName == "serverLog" ) { 
                    ObjectOutputStrewam oos = 
                           new ObjectOutputStrewam( client.getOutputStream());
                    oos.writeObject( message );
               } else if( loggerName == "dblog") { 
                    Pstmt pstmt = dbConnection.prepareStatment( LOG_SQL );
                    pstmt.setParameter(1, message );
                    pstmt.executeUpdate();
                    dbConnection.commit();
               }
      }
 }

Trong mã này, người trung gian là người chứa logic nghiệp vụ để tạo một "kênh" thích hợp để ghi nhật ký và cũng để thực hiện đăng nhập vào kênh đó. Người dàn xếp đang "tạo" chức năng.

Tất nhiên, có những cách tốt hơn để triển khai điều này bằng cách sử dụng tính đa hình, nhưng vấn đề ở đây là cho thấy cách người dàn xếp "thêm" chức năng mới bằng cách kết hợp chức năng hiện có (trong mẫu của tôi không hiển thị rất tiếc) nhưng hãy tưởng tượng người dàn xếp, hãy đọc từ cơ sở dữ liệu máy chủ lưu trữ từ xa nơi đăng nhập, sau đó tạo một máy khách và cuối cùng viết cho máy khách đó in luồng thông báo nhật ký. Bằng cách này, người hòa giải sẽ "hòa giải" giữa các đối tượng khác nhau.

Cuối cùng, mặt tiền là một mẫu cấu trúc, nghĩa là nó mô tả thành phần của các đối tượng, trong khi trung gian là một hành vi, tức là nó mô tả cách các đối tượng tương tác.

Tôi hi vọng cái này giúp được.


Lời giải thích tuyệt vời..Tôi có một câu hỏi liên quan đến điều này. Cách cấu tạo ReentrantLock và AbstractQueueSynchronizer (AQS), điều đó có phù hợp với ví dụ về mẫu Mặt tiền không? Ý tôi là ReentrantLock chỉ cho thấy chức năng của AQS hiện diện bên trong nó dưới dạng hệ thống con.
AKS

Câu trả lời của @RayTayek có mâu thuẫn với câu trả lời của bạn không? Giao thức hòa giải của bạn là một chiều, phải không?
Narek

Tôi không thể tìm thấy bất kỳ trang web nào (kể cả wikipedia) nói rằng một Mediator bổ sung thêm chức năng mới. Bạn có thể chỉ một số tài liệu tham khảo?
nhà phát triển

@developer đây là tài liệu tham khảo , hãy nhìn vào phần dưới.
Dario Fumagalli

13

Tôi đang sử dụng trình dàn xếp để thêm chức năng tệp nhật ký.

Nó hoạt động như thế này:

  • Mục tiêu A nói với người hòa giải rằng họ cần hoàn thành một việc gì đó.
  • Người hòa giải gửi thông điệp đến các đối tượng khách hàng khác nhau.
  • Mục tiêu B thực hiện điều mà Mục tiêu A cần và gửi lại một thông báo thích hợp qua người hòa giải.
  • Trong khi đó, đối tượng C cũng được người hòa giải gửi cả hai thông báo và ghi lại kết quả. Bằng cách đó, chúng tôi có thể nhận thống kê người dùng từ các tệp nhật ký.
  • Mục tiêu D cũng có thể là một trình kiểm tra lỗi, vì vậy nếu Mục tiêu B phản hồi rằng yêu cầu của Mục tiêu A là không thể thực hiện được, thì Mục tiêu D có thể là thứ báo cáo điều đó cho người dùng. Các lỗi hiện có thể được ghi vào một tệp khác với hoạt động thông thường và có thể sử dụng một số phương tiện khác để xử lý (tiếng bíp, bất cứ điều gì) mà đối tượng A không thực sự quan tâm đến.

11

theo các mẫu liên quan, gof nói: Facade (185) khác với Mediator ở chỗ nó tóm tắt một hệ thống con của các đối tượng để cung cấp một giao diện thuận tiện hơn. Giao thức của nó là đơn hướng; nghĩa là, các đối tượng Facade thực hiện các yêu cầu của các lớp hệ thống con nhưng không phải ngược lại. Ngược lại, Mediator cho phép hành vi hợp tác mà các đối tượng đồng nghiệp không hoặc không thể cung cấp và giao thức là đa hướng.


7

Lấy một phép loại suy đơn giản:

Mặt tiền: giống như một bãi đậu xe, khi có cuộc gọi

parkingLot.Out(car1);

mab be a simple chain hoạt động:

{
  car1.StartEngin();      
  attendant.charge();
  car1.driverOut();
}

Người hòa giải: như đèn giao thông.

Có những tương tác giữa ánh sáng và ô tô,

và ô tô được kiểm soát bởi nhà nước của nó.

Tôi mặc dù có thể đây là người dàn xếp "thêm chức năng"


Và về định nghĩa:

Loại mặt tiền: Cấu trúc

Loại người hòa giải: Hành vi

mặt quan tâm hơn về các thành phần được chứa trong giao diện thống nhất ,

và người hòa giải quan tâm đến cách một tập hợp các đối tượng tương tác .


4

Tôi nghĩ rằng sự khác biệt là định hướng: mặt tiền là giao tiếp một chiều giữa khách hàng và mặt tiền; hòa giải viên có thể là một cuộc trò chuyện hai chiều, với các thông điệp qua lại giữa thân chủ và hòa giải viên.


Xin lỗi nhưng sự khác biệt đó thực sự là sai, câu trả lời của mmr là đúng. Mặc dù tôi cũng tin rằng giống như bạn khi lần đầu tiên tôi nhìn họ
Robert Gould

3

Từ cuốn sách "Mẫu thiết kế", KEY của mẫu Dàn xếp được mô tả như sau: "Nó (người dàn xếp) hoạt động như một HUB giao tiếp cho các vật dụng (tức là 'một' nhóm các đối tượng phụ thuộc lẫn nhau)."

Nói cách khác, đối tượng trung gian là siêu đối tượng duy nhất biết tất cả các đối tượng khác trong một nhóm các đối tượng cộng tác và chúng sẽ tương tác với nhau như thế nào. Tất cả các đối tượng khác nên tương tác với đối tượng hòa giải, thay vì lẫn nhau.

Ngược lại, mặt tiền là một "giao diện thống nhất" cho một tập hợp các giao diện trong một hệ thống con - để người tiêu dùng của hệ thống con sử dụng - không phải giữa các thành phần của hệ thống con.


1

Bạn có thể tìm chi tiết về mẫu Mặt tiền trong câu hỏi SE này:

Mẫu thiết kế mặt tiền là gì?

Facade cung cấp một giao diện đơn giản và thống nhất cho hệ thống phức tạp.

Ví dụ trong thế giới thực ( chuyến bay đi + đặt phòng khách sạn ) có sẵn trong bài đăng này:

Mẫu thiết kế mặt tiền là gì?

Mẫu dàn xếp : Xác định một đối tượng đóng gói cách một nhóm đối tượng tương tác. Mediator thúc đẩy kết hợp lỏng lẻo bằng cách giữ cho các đối tượng không tham chiếu đến nhau một cách rõ ràng và nó cho phép bạn thay đổi tương tác của chúng một cách độc lập.

Một ví dụ thực tế về cấu trúc liên kết mạng Mesh đã được cung cấp trong câu hỏi SE bên dưới:

Mediator Vs Observer Các mẫu thiết kế hướng đối tượng

Về truy vấn của bạn trên Mediator sẽ thêm trách nhiệm:

  1. Facade chỉ cung cấp giao diện cho các hệ thống con hiện có . Các hệ thống con hiện tại không nhận thức được bản thân lớp Facade.

  2. Người hòa giải biết về các đối tượng đồng nghiệp . Nó cho phép giao tiếp giữa các đồng nghiệp khác nhau. Trong ví dụ tôi đã trích dẫn trong câu hỏi được liên kết, ConcreteMediator ( NetworkMediator ) gửi thông báo về sự kiện đăng ký và hủy đăng ký của một đồng nghiệp cho tất cả các đồng nghiệp khác.


1

Cả hai đều áp đặt một số loại chính sách cho một nhóm đối tượng khác. Facade áp dụng chính sách từ bên trên và Mediator áp dụng chính sách từ bên dưới. Việc sử dụng Facade có thể nhìn thấy và bị hạn chế, trong khi việc sử dụng Mediator là vô hình và có thể cho phép.

Mẫu mặt tiền được sử dụng khi bạn muốn cung cấp một giao diện đơn giản và cụ thể cho một nhóm đối tượng có giao diện phức tạp và chung chung.

Các Đấng Trung Gian mẫu cũng áp đặt chính sách. Tuy nhiên, trong khi Facade áp đặt chính sách của mình một cách rõ ràng và không bị ràng buộc, thì Mediator lại áp đặt các chính sách của mình theo cách ẩn và không bị hạn chế.

Phát triển phần mềm Agile, Nguyên tắc, Mẫu và Thực tiễn Robert C. Martin.

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.