Рефакторинг некоторых из моего кода

Question

У меня есть класс SalesOrder, который наследуется несколькими различными типами заказов на продажу. У него есть метод ValidateItems (OrderItemList, itemAdditionalValidation), который принимает список элементов заказа и делегата для дополнительной проверки элемента заказа. Каждый из различных заказов на продажу определяет свою собственную версию делегата, а затем передает ее при вызове ValidateItems родительского класса SalesOrder. Делегат принимает объект OrderItem. Класс OrderItem имеет метод Validate (). Метод ValidateItems просматривает список и вызывает Validate для каждого OrderItem, а затем вызывает делегат itemAdditionalValidation и передает его в OrderItem.

До сих пор, когда я хотел проверить элементы, я всегда создавал добавление всех элементов в соответствующий заказ, а затем заказ вызывал ValidateItems и заботился обо всей проверке. Однако теперь я хочу иметь возможность вызывать OrderItem.Validate напрямую, не создавая при этом и порядок, однако я не знаю, как реорганизовать делегата. По сути, я хочу, чтобы OrderItem мог знать, каких делегатов вызывать, основываясь на типе Order, с которым он имеет дело. Есть идеи? Кроме того, любые советы о том, как улучшить мою текущую архитектуру, будут с благодарностью.

Answer 1

Я не совсем уверен, правильно ли я понимаю вашу проблему, но просто предположить, что вы могли бы сделать что-то вроде этого:

• Используйте маркерные интерфейсы, чтобы объявить, с каким типом OrderItem вы имеете дело. Например, у вас могут быть два разных типа OrderItems:

  GoodOrderItemImpl implements GoodOrderItem { }
  BadOrderItemImpl implements BadOrderItem { }
  

• Интерфейсы GoodOrderItem и BadOrderItem, вероятно, расширили бы интерфейс OrderItem, который фактически имеет метод validate (); определено в нем

• Тогда вы можете создать какой-нибудь всезнающий класс, который знает, какой тип дополнительного валидатора соответствует рассматриваемому интерфейсу маркера, например,

  public final class ValidatorGuru {
      // A map that maps GoodOrderItem.class with GoodOrderValidator and BadOrderItem.class with BadOrderValidator
  }
  

• Затем, когда вы захотите проверить GoodOrderItemImpl, например, вы можете использовать интерфейс маркера, чтобы узнать, что он использует GoodOrderValidator в качестве своего дополнительного валидатора (т.е. из ValidatorGuru), а затем вызвать goodOrder.validate (); и затем goodOrderValidator.validate (goodOrder);

Answer 2

Каждый из подклассов SalesOrder предоставляет валидатор orderItem, который используется метоидом ValidateItems ()? Если это метод SalesOrder, то вам не нужно передавать дополнительныйValidator в качестве параметра, он у вас уже есть.

Представляется вполне разумным, чтобы SalesOrder также предложил метод isThisOrderItemValid (item). Он применяет свой валидатор к поставляемому предмету. Или, может быть, метод addOrderItem (item), который добавляет его, если он допустим, но в противном случае выдает исключение.

Как только мы рассматриваем валидацию как принадлежащую SalesOrder, я не вижу проблемы. Использование делегатов или любого другого метода является деталью реализации SalesOrder.