Использование шаблона оформления фасада

В нашем приложении (C#) фасад используется в качестве основного API — фасад будет использоваться самим приложением для работы с ядром. Зная это, вот мои вопросы:

  1. Предполагая, что один из моих основных объектов, который обертывает фасад, имеет рекурсивный бит? Например, фасад предоставляет «GetX» из дерева, и каждый узел должен получить «GetX» из своего поддерева. Должен ли этот узел использовать «GetX» фасада?
  2. Должен ли фасад показывать основные объекты приложению? Например, пользователь хочет построить дерево, добавить узлы, напечатать дерево, вычислить что-то на нем и т. д. Должно ли приложение использовать объект дерева или оно должно запрашивать фасад для его создания, сохранения, проверки и т. д.?

Спасибо.


c# design-patterns facade
person Noich    schedule 16.08.2012    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Фасад — это объект, который обеспечивает упрощенный интерфейс для большей части кода.

Поэтому будьте проще.

  1. Нет. Инкапсулируйте Фасад внутри себя. Я предполагаю, что у вас есть частная реализация для извлечения дерева, используйте ее внутри, предоставляя только общедоступный метод, который возвращает заполненный объект (см. пункт 2).

  2. Нет. Фасад должен делать все, иначе смысла в его создании мало. Возможно, вы захотите создать DTO, который можно использовать в методах фасада, но вы не должны выставлять основные объекты.

person ChrisBint    schedule 16.08.2012
comment
2. HeadFirst отмечает, что фасад упрощается, но внутренние детали остаются доступными для пользователей. Не получу ли я C-подобный код, если мне придется делать все фасадом? Например: создать дерево, добавить узел, получить печать дерева, перевести дерево в XML и т. д.? Если я все равно открываю дерево (путем его создания), не должен ли пользователь использовать его функциональные возможности? - person Noich; 16.08.2012
comment
Хорошо. Вам, вероятно, не нужен фасад, если вы хотите получить доступ к деталям. - person jgauffin; 16.08.2012
comment
Просто цитирую. Я подумал, что мы должны обернуть наше ядро, чтобы оно не было связано с нашим прикладным уровнем (возможно, нам придется предоставить это ядро ​​и другим приложениям). Я имел в виду, что у нас должен быть какой-то API, который будет предоставлять такие функции, как «получить дерево», и будет возвращать дерево, с которым может работать приложение. Объясните, пожалуйста, что не так в этом понятии? - person Noich; 19.08.2012

arrow_upward
1
arrow_downward

Относительно вопроса 1: Как уже говорили другие; Нет. Вместо этого рассмотрите возможность использования отдельного интерфейса для этой операции (здесь может быть применим принцип разделения интерфейса). ?), и сначала получить доступ к операциям на этом интерфейсе через Фасад. При рекурсии внутренний интерфейс можно снова использовать напрямую. Это может обеспечить некоторое разделение задач, а также упростить изменение реализации позже, если это необходимо.

Мне кажется, что сама рекурсия является деталью реализации, а не чем-то, о чем фасад должен знать что-либо. Точно так же фасад — это то, о чем алгоритм реализации не должен знать (т. е. не повторяться через фасад).

Относительно вопроса 2: как насчет определения интерфейсов и для этого? Например. ITree, ITreeNode и т. д., а также включить операции на фасаде для работы с ними. Теперь заставьте реализацию реализовывать эти интерфейсы, предоставляя таким образом необходимые объекты за пределами фасада, не раскрывая основные объекты.

person Kjartan    schedule 16.08.2012

arrow_upward
0
arrow_downward

Фасад обычно оборачивает ваше ядро ​​и дает доступ к определенному набору функций.

  1. вы можете сделать это для согласованности, но если есть другой более простой способ сохранить абстракцию, предоставляемую фасадом, было бы лучше.

  2. Ни один из вашего основного кода не должен быть выставлен (это противоречило бы назначению фасада). Если вы хотите добавить некоторую функциональность, добавьте функцию в свой фасад, которая будет вызывать основные функции внутри вашего фасада.

person MimiEAM    schedule 16.08.2012