Как вы могли бы улучшить этот дизайн кода?

Question

В последнее время я использовал много паттернов стратегии вместе с паттерном фабрики. И я действительно много значу. У меня есть много «алгоритмов» для всего и для фабрик, которые получают алгоритмы на основе параметров. Несмотря на то, что код кажется очень расширяемым, и это так, наличие N фабрик кажется немного злоупотреблением.

Я знаю, что это довольно субъективно, и мы говорим, не видя код, но приемлемо ли это в реальном коде? Вы бы что-нибудь изменили?

Answer 1

ОК - задайте себе вопрос. изменится ли реализация этого алгоритма? Если нет, то удалите стратегию.

Answer 2

I am maintence.

Однажды я был вынужден (моим начальником по паттернам) написать набор из 16 «служб смокинга интерпретатора буфера», используя AbstractFactory и двойной шаблон DAO в C ++ (без отражений, без кода gen). В целом это что-то вроде 20 000 строк противного кода, который я когда-либо видел (не в последнюю очередь потому, что я действительно не знал C ++, когда начинал), и это заняло около трех месяцев.

Поскольку мой старый босс ушел, я переписал их, используя хороший процедурный стиль "прямо вверх и вниз" C ++, с парой фанки-макросов ... каждый сервис похож на 60 строк кода, умноженный на 16. ... всего до 1000 строк действительно SIMPLE кода; так просто, что даже я могу следовать за ним.

Приветствия. Кит.

Answer 3

Насколько сложна работа, которую выполняет завод? Действительно ли создание объекта необходимо абстрагировать к другому классу? Разновидностью фабричного метода является простая в своем классе фабрика. Это действительно работает лучше всего, если какие-либо зависимости уже введены.

Например,

public class Customer
{
  public Customer CreateNewCustomer()
  {
    // handle minimally complex create logic here
  }
}

Что касается злоупотребления стратегией ... Опять же, как объяснил @RichardOD, алгоритм когда-нибудь действительно изменится?

Всегда помните о принципе YAGNI . Вам это не нужно.

Answer 4

Зависит от типа программного обеспечения, над которым я работаю.

Техническое обслуживание требует простого кода, а фабрики НЕ являются простым кодом.

Но расширяемость иногда требует фабрики ...

Так что вы должны принять во внимание оба.

Просто помните, что большую часть времени вам придется поддерживать исходный файл МНОГИЕ раза в год, и вам НЕ нужно будет его расширять.

ИМО, шаблоны следует использовать только в случае крайней необходимости. Если вы думаете, что это может быть полезно через два года, вам лучше использовать их ... через два года.

Answer 5

Разве вы не можете создать AbstractFactory вместо отдельных фабрик?

AlgorithmFactory создает необходимые алгоритмы на основе конкретной фабрики.

Answer 6

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

Answer 7

Всякий раз, когда я внедряю код таким образом, я задаю несколько вопросов:

1. какие компоненты мне нужно заменить для тестирования?
2. какие компоненты я ожидаю отключить или заменить пользователями / администраторами (например, через конфигурацию Spring или аналогичные)?
3. какие компоненты я ожидаю или подозреваю, что они не понадобятся в будущем из-за (возможно) изменения требований?

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