Небольшой фон: мы создаем библиотеку/рамки для работы с научными моделями. У нас есть интерфейс Model, который определяет операции, которые должна реализовывать модель, что довольно мало. То есть: интерфейс Model определяет контракт модели с точки зрения разработчика модели.
Структура добавляет кучу других функций вокруг модели, но прямо сейчас клиентский код должен получить доступ к этой функциональности, используя кучу других классов, таких как ModelInfo, ModelHost, ModelInstance и т.д.
В нашем приложении, использующем эту структуру, мы не хотим иметь дело со всем этим механизмом запуска моделей и т.д. Поэтому мы решили использовать фасад шаблона, чтобы обернуть функциональность фреймворка в простой в использовании объект. (Мы уже применили этот шаблон к другим частям фреймворка с хорошим успехом.)
Вот вопрос: учитывая, что у нас уже есть интерфейс Model, , что было бы хорошим именем для фасадного класса? Интерфейс Model - это контракт между каркасом и модель, а новый класс определит контракт между каркасом и клиентским приложением.
Или, в общем случае: когда у нас есть абстракция, предоставляемая библиотекой или каркасом, , как мы можем назвать "две стороны" абстракции, чтобы четко идентифицировать интерфейсы "поставщик" и "потребитель" абстракция?
(Если это имеет значение, для этого проекта мы используем Java 6.)
Я знаю, что это кажется банальным, но... вы считали, что используете "ModelFacade" в качестве имени класса для класса фасадов? Я думаю, что с документацией, которая указывает, что интерфейс уже был назван Model, он выглядит относительно простым и очень четко определяет, какой шаблон дизайна вы используете.
Как насчет * Провайдера и * Потребителя? Думаю, ты сам это сказал в своем вопросе. Возможно, * Производитель и * Потребитель лучше подходит?
В обсуждениях в нашей команде был предложен другой вариант: мы можем переименовать существующий интерфейс Model в нечто другое и просто вызвать новый фасад Model. На самом деле их можно назвать Model прямо сейчас, потому что они будут жить в отдельных пакетах. (Хотя я не являюсь поклонником одинаково названных классов в разных пространствах имен.)
PureMVC использует singleton с именем ApplicationFacade и регистрирует все модели с помощью методов типа registerProxy, которые определены в IFacade
Похоже, ModelInfo, ModelHost и ModelInstance должны быть членами Model.
См. Https://softwareengineering.stackexchange.com/info/316840/is-it-bad-practice-to-name-a-class-with-a-facade-suffix, чтобы узнать, почему вы, как правило, не должны называть классы с конкретными реализация используется. По сути, однажды вы захотите использовать другую реализацию Model, которая не является фасадом.