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