Как правильно выбрать архитектурные / дизайнерские шаблоны
Я делаю свой собственный исследовательский проект, и я довольно борюсь за правильный выбор архитектурных / дизайнерских шаблонов.
В этом проекте после запуска «системы» мне нужно что-то делать в фоновом режиме (задачи, обработка, отображение данных и т. Д.) И при этом иметь возможность взаимодействовать с системой с помощью, например, клавиатуры и посылать некоторые команды например, «дайте мне статус этого конкретного объекта» или «каковы данные в этом объекте».
Итак, мой вопрос — какие программные / архитектурные шаблоны могут быть применены к этому конкретному проекту? Как должно быть организовано взаимодействие между классами / объектами? Как объекты должны быть созданы?
Можно, например, применить здесь «управляемую событиями архитектуру» или «микроядро»? Некоторые ссылки на полезные ресурсы будут очень благодарны!
Заранее большое спасибо!
Решение
Осторожнее с шаблонами дизайна. Если вы разбросаете их по всему коду, надеясь, что все будет отлично работать, у вас скоро будет нечитабельный, полный беспорядок. Это рецепты, а не решения.
Мой вам совет: возьмите лист бумаги и карандаш и начните рисовать все сущности вашего домена со всеми их реквизитами и посмотрите, как они соотносятся. Если вы хотите серьезно отнестись к этому, вы можете сделать что-то вроде этот.
Определяя свои сущности, стремитесь к высокая сплоченность а также Слабая связь.
Высокая сплоченность означает, что вы должны сохранять сходные функции вместе. В очень простом примере, если у вас есть класс, который читает материал из файла и обрабатывает его, класс имеет низкую сплоченность, поскольку чтение и обработка — это две совершенно разные функции. В этом случае вам нужен класс для каждой функциональности.
Что касается слабой связи, это означает, что ваши сущности должны быть независимы друг от друга. Используя приведенный выше пример, предположим, что вы теперь являетесь счастливым обладателем двух очень сплоченных классов — один, который читает материал из файла (Reader), и другой, который обрабатывает этот материал (Processor). Теперь предположим, что класс Processor имеет экземпляр класса Reader и вызывает его, чтобы получить входные данные. В этом случае мы можем сказать, что оба класса тесно связаны, так как Processor не будет работать без Reader. В мире ООП решением для этого обычно является использование интерфейсов. Вы можете найти аккуратный пример Вот.
Определив начальную модель своего домена и собрав как можно больше знаний о нем, вы можете начать думать об архитектуре реализации. Это где вы можете начать думать об архитектурных шаблонах. Архитектура, управляемая событиями, чистая архитектура, MVP, MVVM … Все будет зависеть от вашего домена. Ваша работа — знать, какой шаблон подойдет лучше всего. Оповещение спойлера: это может быть чрезвычайно трудно сделать правильно даже для опытных инженеров, поэтому не бойтесь потерпеть неудачу.
Наконец, оставьте шаблоны проектирования на этапе реализации. Их использование полностью зависит от ваших задач и решений. Кроме того, не заставляйте их. В идеале вы решите проблему и, ЕСЛИ ПРИМЕНИМО, вы увидите появление паттерна. Поверьте мне, последнее, что вы хотите, это иметь дело дизайн-патетит. Во всяком случае, если вам нужна литература по шаблонам, я полностью рекомендую эта книга. Это здорово, независимо от вашего уровня инженера.
Дальнейшее чтение:
Удачи!
Другие решения
У вас есть фоновая задача, и она действительно может быть использована для прокачки сообщений / очереди событий. Тогда ваша задача переднего плана будет отправлять запросы в этот фоновый поток и асинхронно ожидать результата.
Взгляните на книгу «Шаблоны для параллельного программирования».
Гораздо лучше, если вы проверите книгу для Design Patterns. Мне очень нравится этот.
Например, если вам нужно получить данные из определенного объекта, вам может потребоваться, чтобы шаблон Observer работал на вас, и как только у объекта есть данные, вы (или другой объект) узнаете эти данные и сможете работать с ними. это, с другой моделью (стратегия может работать, это действительно зависит от того, что вы должны сделать).
Если вам нужно что-то делать одновременно, проверьте также шаблон Singleton (ну, отметьте самые важные!).