... большинство сайтов отмечают, что посредник «добавляет функциональность» ...
Фасад раскрывает существующие функциональные возможности только с другой точки зрения.
Медиатор "добавляет" функциональность, поскольку он объединяет различные существующие функции для создания новой.
Возьмите следующий пример:
У вас есть система регистрации. Из этой системы ведения журналов вы можете войти либо в файл, либо в сокет, либо в базу данных.
Используя шаблон проектирования фасада, вы бы «скрывали» все взаимосвязи от существующей функциональности за одним «интерфейсом», который предоставляет фасад.
Код клиента:
Logger logger = new Logger();
logger.initLogger("someLogger");
logger.debug("message");
Реализация может включать взаимодействие многих объектов. Но в конце концов, функциональность уже существует. Вероятно, метод «отладки» реализован следующим образом:
Реализация:
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 );
}
}
Функциональность уже существует. Фасад только скрывает это. В этом гипотетическом случае LoggerManager обрабатывает создание правильного регистратора, а LoggerImpl является частным объектом пакета, который имеет метод «debug». Таким образом, Фасад не добавляет функциональности, он просто делегирует некоторые существующие объекты.
С другой стороны, посредник добавляет новые функциональные возможности, комбинируя различные объекты.
Тот же код клиента:
Logger logger = new Logger();
logger.initLogger("someLogger");
logger.debug("message");
Реализация:
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();
}
}
}
В этом коде посредник - это тот, который содержит бизнес-логику для создания соответствующего «канала» для входа, а также для входа в этот канал. Посредник «создает» функциональность.
Конечно, есть лучшие способы реализовать это с помощью полиморфизма, но смысл здесь в том, чтобы показать, как посредник «добавляет» новые функциональные возможности, комбинируя существующие функциональные возможности (в моем примере это не очень жаль), но представьте, что Посредник, прочитайте из базы данных удаленный хост, на который нужно войти, затем создайте клиента и, наконец, запишите этому клиенту поток печати сообщения журнала. Таким образом, посредник будет «посредничать» между различными объектами.
Наконец, фасад является структурным паттерном, то есть описывает структуру объектов, в то время как медиатор является поведенческим, то есть описывает, как объекты взаимодействуют между собой.
Надеюсь, это поможет.