... większość witryn wskazuje, że mediator „dodaje funkcje” ...
Fasady odsłania jedynie istniejącą funkcjonalność z innej perspektywy.
mediator „dodaje” funkcjonalność, ponieważ łączy w sobie różne istniejące funkcje, aby utworzyć nową.
Weźmy następujący przykład:
Masz system logowania. Z tego systemu rejestrowania można zalogować się do pliku, do gniazda lub do bazy danych.
Używając wzorca projektowego elewacji, można „ukryć” wszystkie powiązania przed istniejącą funkcjonalnością za jednym „interfejsem” tym, który eksponuje fasada.
Kod klienta:
Logger logger = new Logger();
logger.initLogger("someLogger");
logger.debug("message");
Implementacja może obejmować interakcję wielu obiektów. Ale ostatecznie funkcjonalność już istnieje. Prawdopodobnie metoda „debugowania” jest zaimplementowana w następujący sposób:
Realizacja:
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 );
}
}
Funkcjonalność już istnieje. Fasada tylko go ukrywa. W tym hipotetycznym przypadku LoggerManager obsługuje tworzenie poprawnego programu rejestrującego, a LoggerImpl jest prywatnym obiektem pakietu, który ma metodę „debugowania”. W ten sposób Fasada nie dodaje funkcjonalności, a jedynie deleguje ją do niektórych istniejących obiektów.
Z drugiej strony mediator dodaje nową funkcjonalność, łącząc różne obiekty.
Ten sam kod klienta:
Logger logger = new Logger();
logger.initLogger("someLogger");
logger.debug("message");
Realizacja:
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();
}
}
}
W tym kodzie mediator jest tym, który zawiera logikę biznesową do utworzenia odpowiedniego „kanału” do logowania, a także do logowania się do tego kanału. Mediator „tworzy” funkcjonalność.
Oczywiście są lepsze sposoby na wdrożenie tego przy użyciu polimorfizmu, ale chodzi o to, aby pokazać, w jaki sposób mediator „dodaje” nową funkcjonalność, łącząc istniejącą funkcjonalność (w moim przykładzie nie było bardzo przykro), ale wyobraź sobie mediatora, przeczytaj z bazy danych hosta zdalnego, z którego należy się logować, a następnie tworzy klienta i na koniec zapisuje w strumieniu wydruku tego klienta komunikat dziennika. W ten sposób pośrednik „pośredniczy” między różnymi przedmiotami.
Wreszcie fasada jest wzorem strukturalnym, czyli opisuje kompozycję obiektów, podczas gdy mediator jest behawiorystą, to znaczy opisuje sposób interakcji obiektów.
Mam nadzieję, że to pomoże.