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