Выбор шаблона дизайна

Question

Мне нужно разработать приложение, похожее на внутреннюю почтовую систему. Однако это всего лишь курсовой проект. Нет сети требуется. Профессор просто заставляет нас использовать обсуждаемые структуры данных для работы. Тем не менее, у меня возникли проблемы с выбором дизайна приложения. Позвольте мне кратко объяснить, что я должен делать, и тогда я поделюсь своими мыслями.

Думаю, было бы неплохо, если бы вы знали, что это приложение на основе командной строки. Графический интерфейс не задействован.

Внутренняя почтовая система состоит из 5 возможных состояний. Общий, Администратор, Пользователь, Модератор и Составить. Возможно быть только в одном состоянии за один раз. Когда приложение запускается, оно переходит в общее состояние по умолчанию. Единственная возможная команда в этом состоянии - войти в какую-либо другую учетную запись (Пользователь, Администратор, Мод.). У пользователя есть основные команды, такие как чтение его сообщений, отправка (создание) новых сообщений другому пользователю, удаление сообщений, выход из системы, и еще пару. Пользователь может перейти в одно из двух состояний: Составить или Общее. Чтобы перейти в состояние Compose, пользователь должен использовать команду compose. В этом состоянии вы пишете сообщение другому пользователю. Как только вы закончите составление сообщения, вы вернетесь в состояние пользователя. Единственный способ, которым пользователь может вернуться к общему, - это выйти из системы.

Admin (который наследует поведение пользователя) и Mod в значительной степени одинаковы. Они также могут изменять состояния.

Вот краткая информация о том, как можно изменить состояние

General |----->Admin
        |   |---->User(limited)  
        |   |---->Compose
        |
        |----->Moderator  
        |  
        |----->User  
        |   |---->Compose 

Я новичок в разработке шаблонов. Я много читал о них в последнее время. Тем не менее, это будет первый раз, когда я буду их реализовывать. Если одно из моих предложений покажется странным, пожалуйста, дайте мне знать.

Государственный паттерн кажется отличной идеей. Я позволяю мне динамически изменять состояние объекта. Однако не во всех штатах используются одинаковые методы. Администраторы имеет больше методов, чем пользователь. Модератор не имеет методов от администратора или пользователя. Вы можете использовать только General для входа в систему. Я думаю, что это ограничит возможность использования State Pattern. Есть ли у вас какие-либо предложения для какого-то другого шаблона?

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

\         /  
| Compose | <---- top (current state)  
|  User   |  
| General |  
-----------

У вас есть идеи, как я могу это реализовать? Это вообще возможно? Хотя мне больше всего нравится Java, C ++ или псевдокод в порядке.

Answer 1

Я думаю, что есть смешение двух аспектов, которые вы должны различать ..

Пользователь , Администратор и Модератор являются ролями , а Общие , LogedIn и Составляют , являются состояниями . Таким образом, я думаю, что вы должны объединить оба состояние и роль шаблоны проектирования вместе.

Answer 2

Хороший шаблон дизайна - это "Ролевая модель объекта" . Может применяться в контексте, где:

• вы хотите обрабатывать ключевую абстракцию в разных контекстах и ​​не хотите помещать результирующие контекстно-зависимые интерфейсы в один и тот же интерфейс класса.
• вы хотите динамически обрабатывать доступные роли, чтобы их можно было присоединять и удалять по требованию, то есть во время выполнения, а не исправлять их статически во время компиляции.
• Вы хотите прозрачно обрабатывать расширения и должны сохранить идентичность логического объекта полученного объект конгломерат.
• вы хотите, чтобы пары ролей / клиентов были независимы друг от друга, чтобы изменения роли не влияли на клиентов которые не заинтересованы в этой роли.

В этом шаблоне использовались три элемента: компонент (здесь: ваш пользователь), состоящий из ядра компонента , который по существу управляет ролями, и роли компонента , которые предоставляет ролевые способности. Администратор , Пользователь , Модератор и т. Д. - это роли в вашем контексте.