Какое хорошее название для фасадного класса?

Question

Немного предыстории: мы создаем библиотеку / фреймворк для работы с научными моделями. У нас есть интерфейс Model, который определяет операции, которые должна выполнять модель, что является довольно минимальным. То есть: интерфейс Model определяет контракт модели с точки зрения разработчика модели .

Фреймворк добавляет кучу других функций в модель, но сейчас клиентский код должен получить доступ к этим функциям, используя кучу других классов, таких как ModelInfo, ModelHost, ModelInstance и т. Д.

В нашем приложении, которое использует эту платформу, мы не хотим фактически иметь дело со всем этим механизмом запуска моделей и т. Д. Поэтому мы решили использовать шаблон фасада , чтобы завершить функциональность фреймворка в простом в использовании объекте. (Мы уже применили этот шаблон к другим частям фреймворка с хорошим успехом.)

Вот вопрос: учитывая, что у нас уже есть интерфейс Model, , что было бы хорошим названием для класса фасада? Интерфейс Model - это контракт между платформой и модель реализации , а новый класс будет определять контракт между платформой и клиентским приложением .

Или, в более общем плане: когда у нас есть абстракция, предоставляемая библиотекой или инфраструктурой, как мы можем назвать «две стороны» абстракции, чтобы четко идентифицировать интерфейсы «провайдера» и «потребителя» для абстракция ?

(Если это имеет значение, для этого проекта мы используем Java 6.)

Answer 1

Я знаю, что это кажется банальным, но ... вы рассматривали возможность использования "ModelFacade" в качестве имени класса для фасада? Я думаю, что с документацией, которая указывает, что интерфейс уже был назван Model, он кажется относительно простым и очень ясно дает понять, какой шаблон проектирования вы используете.

Answer 2

В обсуждениях внутри нашей команды был предложен другой вариант: мы можем переименовать существующий интерфейс Model во что-то другое, и просто вызвать новый фасад Model. На самом деле, они оба могут называться Model прямо сейчас, потому что они будут жить в отдельных пакетах. (Хотя я не фанат классов с одинаковыми именами в разных пространствах имен.)

Answer 3

Как насчет * поставщика и * потребителя?Я думаю, что вы сами сказали это в своем вопросе.Возможно, * Производитель и * Потребитель лучше подходят?

Answer 4

Похоже, ModelInfo, ModelHost и ModelInstance должны быть членами Model.

См. https://softwareengineering.stackexchange.com/questions/316840/is-it-bad-practice-to-name-a-class-with-a-facade-suffix, почему вы вообще не должны называть классы с конкретной используемой реализацией.По сути, однажды вы захотите использовать другую реализацию Model, которая не является фасадом.

Answer 5

PureMVC использует синглтон с именем ApplicationFacade и регистрирует все модели с помощью таких методов, как registerProxy, которые определены в IFacade