Шаблон проектирования для применения последовательного терминала - PullRequest
4 голосов
/ 01 февраля 2011

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

  • Приложение с последовательным терминалом (очень похоже на HyperTerminal)
  • Приложение для анализа данных (сортирует и отображает последовательные данные в соответствии с определенными критериями)
  • Приложение декодирования (будет обрабатывать последовательные данные и отображать связанную информацию из базы данных)

В какой-то момент в будущем я хотел бы объединить эти три приложения в одно. Однако это далеко не приоритет.

Я разделил фреймворк на три отдельные части - графический интерфейс (интерфейсы просмотра), серверную часть (интерфейсы контроллера) и обработчик настроек (интерфейс ISettingsHandler). Однако я уже столкнулся с некоторыми проблемами циклической зависимости (ISettingsView пришлось перенести в то же пространство имен, что и ISettingsHandler), что указывает на дальнейшие проблемы в будущем.

Мои требования для каждого приложения следующие:

  • Последовательный терминал - графический интерфейс должен иметь возможность передавать данные в последовательный порт и из него, отображать и изменять настройки, а также отправлять файлы
  • Приложение для последовательного анализа - графический интерфейс должен иметь возможность извлекать входящие последовательные данные, отображать и изменять настройки
  • Приложение декодирования - GUI должен иметь возможность получать входящие последовательные данные

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

Current pattern diagram

РЕДАКТИРОВАТЬ: Чтобы уточнить, каждый из трех «частей» каркаса находятся в разных пространствах имен.

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

Ответы [ 3 ]

2 голосов
/ 03 февраля 2011

Одним из принципов дизайна является «Голливудский принцип», который гласит: «Не звоните, мы вам позвоним» (из головы, сначала шаблоны проектирования)

Круговая зависимость является распространенной проблемой. Чтобы избежать этого, следуйте этому принципу.

Не ссылаться на интерфейсы / классы более высокого уровня на нижнем уровне. Классы более высокого уровня должны использовать интерфейсы / классы более низкого уровня.

Например, ISettingsHandler должен иметь ссылку на IController, а не наоборот. Даже когда вы реализуете конкретные классы, старайтесь следовать принципу.

Ваш код будет более понятным.

1 голос
/ 01 февраля 2011

Если вы работаете с циклическими зависимостями, вам нужно извлечь общие ресурсы в другой проект (например: поместить все интерфейсы в проект MyProject.Contracts).Однако, если вы следуете правильному наслоению, у вас не должно быть этих проблем.

0 голосов
/ 09 июня 2011

Здесь вы можете использовать интерфейсную зависимость, основанную на принципах голливудского принципа

...