帮助设计一个订单管理类 [英] Help designing a order manager class

问题描述

所以，我有一个订单管理器类，看起来像：

So I have an order manager class that looks like:

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


     }
}

现在，这里的关键是要有一个灵活/ testible设计。
我很担心能写出解决此计算方法坚实的单元测试。

Now, the point here is to have a flexible/testible design. I am very concerned about being able to write solid unit tests around this Calculate method.

注意事项：

     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

如果我只是创造一个税收和运输Manager类，并在构造税/运费的工厂？ （究竟如何我设计我的OrderManager）班的？

Should I just create a Tax and Shipping Manager class, and have a tax/shipping factory in the constructor? (exactly how I have designed my OrderManager) class?

（我能想到的唯一的事情，在我什么条件失踪，是国际奥委会，但我不介意这一点，不需要那么在我看来，抽象的额外级别）。

(the only thing that I can think of, in terms of what I am "missing", is IoC, but I don't mind that and don't need that extra level of abstraction in my view).

推荐答案

只是一个想法：

您计算（）方法采取任何参数，返回不信邪，作用于私有字段是不是我会怎么做。我会写因为这发生在一些数字，一个IShippingProvider和ITaxJurisdiction并返回一个当年总体的静态方法。这样，你有机会使用memoization的缓存昂贵的呼叫UPS和你的税表。

Your Calculate() method taking no parameters, returning nothing and acting on private fields is not how I would do it. I would write it as a static method that takes in some numbers, an IShippingProvider and an ITaxJurisdiction and returns a dollar total. That way you have an opportunity to cache the expensive calls to UPS and your tax tables using memoization.

会不会是我pjudiced针对工作就像公共方法$ P $。他们烧毁我过去试图绑定到控件，使用code发电机等。

Could be that I'm prejudiced against public methods that work like that. They have burned me in the past trying to bind to controls, use code generators, etc.

编辑：作为依赖注入/ IOC，我不认为有必要。这就是界面都做。你不会被加载了古怪类的全阵列一样的重量/ ZIP code组合的一些实现。

as for dependency injection/IOC, I don't see the need. This is what interfaces were made for. You're not going to be loading up a whole array of wacky classes, just some implementations of the same weight/zipcode combo.

这就是如果我是你的老板，我会说什么。

That's what I would say if I were your boss.

这篇关于帮助设计一个订单管理类的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！