Помогите разработать класс менеджера заказов

Question

Итак, у меня есть класс менеджера заказов, который выглядит так:

public class OrderManager
{
     private IDBFactory _dbFactory;
     private Order _order;

     public OrderManager(IDBFactory dbFactory)
     {
         _dbFactory = dbFactory;
     }


     public void Calculate()
     {

          _order.SubTotal
          _order.ShippingTotal
          _order.TaxTotal

          _order.GrandTotal


     }
}

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

Вопросы:

     1.  Shipping has to be abstracted out, be loose coupled since the implementation of shipping could vary depending on USPS, UPS, fedex etc.  (they have their own API's).
     2. same goes with calculating tax

Должен ли я просто создать класс диспетчера налогов и отгрузок и иметь в конструкторе фабрику налогов / отгрузок? (как именно я разработал свой класс OrderManager)?

(единственное, о чем я могу подумать, с точки зрения того, что мне «не хватает», - это IoC, но я не против, и мне не нужен этот дополнительный уровень абстракции, на мой взгляд).

Answer 1

Я думаю, что МОК поможет с реализацией правильных конкретных классов, но вы все равно должны получить свой дизайн так, как вы этого хотите. Я действительно думаю, что вам нужно абстрагировать доставку с помощью интерфейса, который вы можете реализовать с помощью класса для каждого из ваших грузоотправителей (USPS, UPS, FEDEx и т. Д.) И который мог бы использовать класс Factory (ShippingManager), чтобы передать правильный или зависит от МОК, чтобы сделать это для вас.

public interface IShipper
{
//whatever goes into calculating shipping.....
 decimal CalculateShippingCost(GeoData geo, decimal packageWeight);
}

Вы также можете просто добавить конкретные классы IShipper и ITaxer в ваш OrderManager, и вы рассчитываете вызовы методов только для этих классов .... и можете легко использовать IOC для обработки этого.

Answer 2

Просто мысль:

Ваш метод Calculate (), не принимающий параметров, ничего не возвращающий и работающий с закрытыми полями, - это не то, что я хотел бы сделать. Я бы написал его как статический метод, который принимает несколько чисел, IShippingProvider и ITaxJurisdiction и возвращает сумму в долларах. Таким образом, у вас есть возможность кэшировать дорогостоящие звонки в UPS и таблицы налогов с помощью напоминаний.

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

РЕДАКТИРОВАТЬ: что касается внедрения зависимости / IOC, я не вижу необходимости. Это то, для чего были созданы интерфейсы. Вы не собираетесь загружать целый массив дурацких классов, только некоторые реализации одного и того же сочетания веса / почтового индекса.

Я бы сказал, если бы я был твоим боссом.

Answer 3

Что ж, вы уже переходите к внедрению зависимостей в своем подходе, так почему бы не использовать всю нагрузку и использовать какой-то контейнер IoC, чтобы справиться с этим для вас?

Да, если вы хотите абстрагироваться, создайте для него отдельный класс. Если вы хотите действительно модульное тестирование того, что осталось, абстрагируйте интерфейс и используйте фиктивное тестирование. Проблема в том, что чем больше вы абстрагируетесь от этого, тем больше нужно работать вместе, и тем больше вы захотите использовать какой-то фреймворк IoC.

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

Answer 4

Я бы взял метод Calculate в класс. В зависимости от ваших обстоятельств, OrderCalculator может потребоваться информация о НДС, валюте, скидках, ...

Просто мысль.