Java-метод «Сканер» против шаблона проектирования Facade GoF
Я изучаю шаблоны проектирования, чтобы улучшить свои навыки программирования. Прямо сейчас я изучаю шаблон проектирования фасада.
Я могу путать себя, но, например: разве Scanner не фасад?
Обратите внимание, что я не спрашиваю, что такое фасад, а пытаюсь определить, является ли он сканером.
Ну, я объявляю это, чтобы я мог использовать определенные функции, не связываясь со сложными и более глубокими функциями, верно?
Я заявляю
Scanner sc = new Scanner(System.in);
Так что я могу:
String x = sc.nextLine();
Не совсем. Scanner обеспечивает функциональность, которой нет у InputStream, поэтому на самом деле это не Фасад.
Ответы 2
Это хороший пример класса, который упрощает API и делает его понятным и близким к тому, для чего он используется. Когда мы хотим прочитать данные от пользователя в консольном приложении, InputStream будет сложно использовать. Давайте посмотрим на некоторое определение шаблона Фасад и сопоставим его с классом Scanner:
Намерение
- Обеспечить унифицированный интерфейс для набора интерфейсов в подсистеме. Фасад определяет высокоуровневый интерфейс, который делает подсистему проще в использовании.
- Оберните сложную подсистему более простым интерфейсом.
Scanner класс соответствует обоим пунктам выше.
Контрольный список
- Определите более простой унифицированный интерфейс для подсистемы или компонент.
- Разработайте класс-оболочку, который инкапсулирует подсистему.
- Фасад/обертка отражает сложность и сотрудничество компонента и делегирует соответствующие методы.
- Клиент использует (подключен) только Фасад.
- Подумайте, будут ли добавлены дополнительные фасады.
Scanner класс соответствует всем вышеперечисленным пунктам. Итак, мы можем рассматривать Scanner как фасад для InputStream.
Идеально! Спасибо. Я думаю, что иду по правильному пути
Scanner не унифицирует какой-либо набор интерфейсов и не упрощает интерфейс Readable, который он обертывает. API Scanner намного сложнее, чем Readable.
@jaco0646, Facade тоже можно упростить API для одного interface. Конечно, гораздо яснее видеть это, когда у нас есть более одного, но одного достаточно. Возможно, он намного сложнее API, чем Readable, но его проще использовать, когда мы читаем данные из консоли. parseInt, nextLine, hasNextLine намного проще понять и использовать, чем read следующие байты. Кроме того, мы можем создавать другие Facade поверх Scanner, что упрощает использование консоли для наших требований. Например, если нам нужно прочитать только несколько чисел из консоли, мы можем ограничить ScannerAPI только необходимыми методами.
Фасад объединяет отношения «один ко многим» в отношения «один к одному» для своих клиентов. Они становятся проще, потому что зависят от одного (высокоуровневого) фасада, а не от множества (низкоуровневых) отдельных компонентов. Сам Фасад берет на себя множество низкоуровневых зависимостей (и делегирует их).
Отношение Scanner к его Readable source — это простая старая композиция объектов. Нет консолидации зависимостей. Хотя верно то, что Scanner обеспечивает новую функциональность и является абстракцией более высокого уровня, чем Readable, это верно для многих или большинства отношений композиции.
Фасад одновременно уменьшает зависимости (связь) и увеличивает абстракцию для своих клиентов. Обратите внимание, что диаграммы шаблона фасада всегда показывают стрелки несколько, исходящие от объекта фасада.
Возможный дубликат Какова схема оформления фасада?.