Java: случай рефакторинга (M и C из MVC?)

Question

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

Концептуально, скажем, у меня есть низкоуровневый интерфейс DeviceIOChannel с несколькими методами (getInputStream, getOutputStream и некоторыми другими для управления обнаружением соединения / разъединения и т. Д.), Реализованными одним или несколькими классами, которые обрабатывают I / O для различных типов каналов передачи данных (RS232, TCPIP и т. Д.). Некоторая часть моего программного обеспечения, назовем его классом Device, предназначена для управления вводом / выводом (синтаксический анализ ввода, построение вывода, управление низкоуровневыми конечными автоматами), но без знания деталей того, как DeviceIOChannel делает это. вещь (так что я могу использовать его с RS232 или TCPIP без изменения класса Device). Поэтому я, вероятно, передам DeviceIOChannel как параметр конструктору Device. Я также хотел бы представить какую-то модель данных внешнему миру.

1. Правильно ли звучит мое разбиение DeviceIOChannel / Device?
2. Device необходимо активно делать некоторые вещи в рабочем потоке. Какой лучший способ настроить это? Должен ли он создавать и управлять своими Thread или ScheduledExecutorService? Или я должен передать ScheduledExecutorService в качестве параметра конструкции?
3. любые мысли (ссылки на хорошие статьи в Интернете были бы идеальными!) О том, должен ли класс Device иметь метод startup(), отличный от конструкции? (выполнение всей инициализации в сборке заставляет меня нервничать ... кажется, что создание экземпляра класса должно быть быстрым, а затем длинные вещи должны быть зарезервированы для фазы инициализации или запуска, которая наступит позже.)
4. А как насчет того, чтобы иметь класс Device с парой методов выключения / перезапуска, в отличие от отсутствия выключения +, требующего создания нового экземпляра Device?
5. Я все еще новичок в архитектуре MVC: имеет ли смысл создавать DeviceDataModel интерфейс, который реализует Device, или мне нужен какой-то отдельный класс DeviceDataModel, который каким-то образом имеет двустороннюю связь с Device класс?

Answer 1

Чтобы ответить на ваш вопрос по одному баллу за раз.

1. Да, это звучит разумно.
2. Да, передача абстракции для вашего потока определенно сделает класс намного более тестируемым. Две зависимости в конструкторе не кажутся необоснованными.
3. Наличие метода запуска добавляет больше накладных расходов (при вызовах методов вы должны проверять, был ли запущен запуск, вы не можете это предположить), однако я согласен, что такая сетевая активность в конструкторе всегда выглядит странно для меня, когда я ее вижу , Я думаю, что это действительно вопрос стиля, но одно преимущество отдельного метода заключается в том, что если вам нужно отладить или зарегистрировать состояние перед запуском, ваш класс Device может выразить свою конфигурацию как экземпляр, а не сделать невозможным для чего-то другого получить ручку на объекте.
4. Я думаю, что ответ на этот вопрос почти полностью зависит от того, как вы справитесь с # 3. У API без сюрпризов не было бы способа перезапустить, если бы он начинался в своем конструкторе, и был бы способ, если бы он начинался через метод.
5. Учитывая сетевой характер ввода-вывода этого класса, интерфейс DeviceDataModel сделает остальную часть кода гораздо более тестируемой. Тем не менее, он не должен быть реализован непосредственно классом Device, а скорее возвращен из метода класса Device в качестве внутреннего класса, чтобы он мог легко взаимодействовать с классом устройства, но при этом оставался бы тем, что можно высмеять или заглушить во время тестирования. , По крайней мере, до тех пор, пока сериализация DeviceDataModel не является обязательной.