Использование класса Builder для воссоздания набора дочерних объектов с использованием DI? - PullRequest
Новая
       15

Использование класса Builder для воссоздания набора дочерних объектов с использованием DI?

3 голосов
/ 16 октября 2011

У меня есть класс Request, который используется для извлечения файлового ресурса из внешнего процесса, используя метод RetrieveResource(). Этот метод занимает около 10-15 секунд. Кроме того, класс Request содержит четыре дочерних объекта, которые создаются с использованием внедрения зависимостей во время создания класса для доступа к содержимому запрошенного файла.

Класс Request создается из основного класса проекта. Основной класс звонит RetrieveResource() примерно каждые 30 секунд. После каждого вызова может потребоваться настроить определенное свойство, например свойство A, одного или нескольких дочерних объектов класса Request.

Мне было бы интересно услышать мнения о наилучшем способе достижения этой цели. В следующем списке описаны три подхода, которые можно использовать для изменения значения свойства A:

  1. Основной класс явно устанавливает значение свойства A для каждого дочернего объекта объекта Request, вызывая свойство напрямую. Например, Request.Object1.PropertyA = newValue;

  2. Создайте метод в классе Request для обновления значения свойства A для каждого дочернего объекта, например, UpdatePropertyA()

  3. При создании экземпляра класса Request передайте класс построителя, который отвечает за создание нового экземпляра Request, включая создание каждого из четырех объектов с использованием DI. Класс построителя содержит свойство, например, Свойство A, которое затем используется для установки значения свойства имени для каждого дочернего объекта класса Request.

Рад слышать мысли. Спасибо.

1 Ответ

1 голос
/ 17 октября 2011

Проблема первых двух подходов, которые вы предложили, заключается в том, что они не являются гибкими.Если впоследствии ваши требования изменятся (скажем, у вас будет больше дочерних объектов, или свойство A будет просто переименовано и т. Д.), Это приведет к изменениям в основном классе или в классе Resource, что не очень хорошо.Более того, с моей точки зрения, эти классы не должны обновлять свойство A.

Лично я бы предложил немного измененный третий подход, поскольку он перемещает всю логику обновления в объект построителя, который являетсяхорошее и гибкое решение.Я бы сказал, что у этого объекта должен быть метод, скажем BuildUp(Request instance), и внутри этого метода должно происходить все обновление.То, как вы реализуете фактическое обновление, здесь не имеет значения - все это будет оставлено в стороне в специальном классе, и в случае каких-либо изменений оно может быть изменено в мгновение ока, без изменения основной логики классов приложения..

Кроме того, вы можете создать интерфейс для этого компоновщика и работать с интерфейсом только в коде класса Resource.Это будет основной класс, который будет знать о фактической реализации используемого компоновщика.Таким образом, в случае каких-либо изменений можно заменить реализацию компоновщика одной строкой.

...