Разделение проблем при добавлении новых типов

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

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

Я попытаюсь упростить это, чтобы я мог поместить его в поле вопроса.

В мире есть FruitService с интерфейсом SNMP. Задача моего издателя - собрать эти данные, а затем опубликовать их.

  1. Итак, для каждого нового Fruit, который мы решили опубликовать, я создаю класс, который знает, как вытащить атрибуты для этого фрукта через SNMP.
  2. Internal Fruit переводится в DTO (те же объекты, что и для общения с клиентом # 1 (RMI)).
  3. Кэш обновляется и проверяется на наличие изменений для асинхронных уведомлений.
  4. Класс для перевода плода в схему xml, используемую другим клиентом (# 2).
  5. Класс для перевода плода в простые пары атрибут /значение, используемые другим клиентом (# 3).

В конце я создаю 5 классов и еще 8 редактирую, чтобы подключить новый тип. Это не очень много работы; пару часов, чтобы написать код, тест и регистрацию для простого типа. Обратите внимание, что в типах фруктов не существует много общего (например, груша и кокос), поэтому большинство общих абстракций основаны на процессе обновления данных, а не на самих данных.

Мои проблемы с дизайном:

  1. Интерфейс SNMP меняется 2-3 раза в год.
  2. Схема xml (клиент 2) изменяется 10 раз в год.
  3. Добавление новых типов происходит реже, обычно, когда кто-то обходит его. Но, возможно, если бы это было проще ...

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

Есть ли способ или пример, на которые я мог бы обратить внимание? Идея, которую мне не хватает? Я применяю SRP неправильно, и должен быть тип Apple, который говорит SNNP, xml-схему, DTO и т. Д.

alt text

ИЗМЕНИТЬ:

Клиент № 1, клиент RMI, написан на заказ при добавлении нового фрукта, чтобы воспользоваться всеми возможностями фруктов. Поэтому, если мы решим вытащить банановую информацию из FruitService, мы также напишем клиента, который позволит вам очистить банан, получить уведомление, когда он созрел, и сообщить вам, к какой группе он принадлежит, - наряду с основными атрибутами фруктов, такими как размер, вес, цвет, время до гнилой и т. д.

7 голосов | спросил Steve Jackson 9 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 09 Sep 2010 17:40:39 +0400 2010, 17:40:39

1 ответ


1

Мое первое впечатление о том, что ваш дизайн нуждается в некотором рефакторинге, чтобы быть более ориентированным на объекты. У вас разные типы для разных структур, однако поведение важно. Если это возможно, а не создавать новый тип Fruit, описать общую структуру фруктов и создать объекты для конкретного фрукта. Таким образом, вы можете включить поведение, которое будет описывать структуру в Fruit и создавать общие классы перевода, которые будут использовать информацию о структуре для создания 8 объектов, которые вам нужны при добавлении нового типа фруктов. Это можно сделать также с помощью метапрограммирования, но зависит от вашего языка, навыков и усилий, необходимых для создания чего-то подобного.

Итак, идея состоит в том, чтобы перевести Coconut.getMilk () и Pear.getSeeds () в Fruit.getAttributes () и так далее. Это немного помогает?

ответил Gabriel Ščerbák 10 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 10 Sep 2010 15:03:56 +0400 2010, 15:03:56

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132