Как лучше организовать классы / пакеты в рамках, чтобы клиент моего приложения мог легко их расширить?

Question

Давайте предположим, что я отвечаю за разработку игры Scrabble, так как одним из основных требований клиента является возможность позже опробовать различные способы и режимы игры.Я уже сделал дизайн, который достаточно гибок, чтобы поддерживать такие изменения.Остается только один вопрос: что выставить клиенту (модификаторы доступа к объектам) и как его организовать (как выставить мои объекты в пространствах имен / пакетах).

Как определить вещи так, чтобы клиентМогут ли оба легко использовать мою стандартную реализацию (стандартную игру Scrabble), и при этом иметь возможность вносить все изменения, которые ему нужны? Я думаю, что мне нужно, это своего рода фреймворк, над которым он может работать.

Я организовал свои классы / интерфейсы в нестрогой многоуровневой системе:

Типы данных

Содержит основные типы данных, которые могут использоваться во всей системе. Доступ к этому пакету и его членам возможенКто-нибудь в системе. Все ее члены являются общедоступными.

Домен

Содержит все определенные мной интерфейсы, и это может быть полезно, чтобы иметь возможность создавать новые реализации Scrabble клиента. Также содержит значениетипы, такие как Piece, которые используются в игре. Все ее участники являются открытыми.

Реализации

Содержит всеl необходимые классы / код для реализации моей стандартной игры Scrabble в пакете Implementations.StandardScrabble.Если клиент решит реализовать другие варианты игры, он может создать их, например, в Implementations.XYZ.Все эти классы защищены пакетом, и единственное, что доступно снаружи пакета, - это игровой фасад.Используются пакеты «Домен» и «Типы данных».

UI

Содержит класс пользовательского интерфейса, который я реализовал, чтобы и клиент, и пользователи программы могли запустить игру (моя реализация).Доступ ко всем остальным слоямв основном реализую почти все сам (разделяю в Домене интерфейсы, но он почти ничего не может с ними сделать).Я чувствую, что, возможно, мне следует передать все классы Реализации в Домен, а затем иметь только Фасад, который создает мой стандартный Scrabble в пространстве имен Реализации?

Как бы вы подошли к этому?Есть ли рекомендуемые материалы о том, как создавать программы такого типа (в основном, фреймворки)?

Спасибо

Answer 1

Какой бы дизайн вы ни придумали, я бы ошибался, скрывая как можно большую часть реализации.Как только вы представите реализацию, вы не сможете забрать ее обратно (если вы не готовы вести пламенную войну со своей клиентской базой).Вы всегда можете предоставить реализации по умолчанию позже, как считаете нужным.

Как правило, я бы начал с предоставления только тонких интерфейсов.Затем, перед предоставлением абстрактных классов, я мог бы предложить вспомогательные классы (например, Factories, Builders и т.1010 * Джошем Блохом за полезные общие приемы при разработке объектно-ориентированного кода.

Answer 2

Для алгоритмов и стратегий я бы определил интерфейсы и реализации по умолчанию и предоставил абстрактные суперклассы, которые расширены вашими собственными реализациями, так что весь шаблонный код находится в абстрактном суперклассе. Кроме того, я бы позволил клиенту подкласс вашего подкласса. Просто сделайте больше, чем один impl, и вы увидите, что и где разместить.

Но самое главное: дайте вашему клиенту код. Если ему нужно понять, где разместить свой код, он также сможет увидеть то, что вы кодировали. Не надо прятать вещи.

Answer 3

Я думаю, что вы пытаетесь дать слишком много свободы клиенту.Это должно делать вещи, с которыми вам трудно справиться.Исходя из того, что вы описали, кажется, что клиент сможет изменять почти все части вашей игры - модель, логику, пользовательский интерфейс ... Я думаю, что было бы лучше ограничить изменяемые области в вашем приложении, но показать некоторые из них с помощью общих Plugin набор интерфейсов.Это также облегчит работу пользователя - ему нужно только узнать, как работают плагины, а не логику всего приложения.Определите области для ваших плагинов, если хотите - плагин пользовательского интерфейса, плагин игрового режима и так далее.Многие производственные приложения и игры работают таким образом (вспомните Diablo II и его УДИВИТЕЛЬНОЕ разнообразие плагинов!).

Answer 4

MVC / Compund Pattern

Вы можете выпустить более раннюю версию вашего пакета. позже вы можете обновить его в соответствии с требованиями пользователя.

Если вы используете MVC или другой составной шаблон с умом, я думаю, вы также можете легко обновить свой пакет.