petshop面向接口的思考

petshop是采用面向接口的编程思想，接口的有点我之前知道了一些，它是一种规范，更易团队合作开发。

但，接口真的就只有这点优点吗？来看看petshop的接口是怎样实现吧，就说数据访问层吧：

IDAL定义了数据访问层的接口，SQLServerDAL对接口进行实现，然后在抽象工厂DALFactory中对DAL进行实例化。

DALFactory是通过反射（Reflection）和配置文件实现依赖注入。

真正的企业项目我没有做过，好像部署好的网站不好去修改，特别后面维护的时候最好不要去修改代码，因为这样网站还要重新部署，

这时接口优势就体现出来了。我找了好久找不到一个号的例子，来看看网上的这个例子吧（我觉得这个例子不是很好）：

比如在Cart类中有Total属性，是计算所有物品的总价，PetShop在这里的业务逻辑很简单，直接就是单价×数量，但是遇到其他业务逻辑比如买300返100，它就傻眼了，不得不去修改源码。可以抽象出一个接口IOnSaleStrategy，
public interface IOnSaleStrategy 
{
 decimal CalculateTotalPrice(Dictionary cartItems);
}

如此一来，我们可以为Cart类定义一个有参数的构造函数：
private IOnSaleStrategy m_onSale; 
public Cart(IOnSaleStrategy onSale)
 {
 m_onSale = onSale;
 }

那么Total属性就可以修改为：
public decimal Total 
{ 
get {return m_onSale.CalculateTotalPrice(cartItems);}
 }

上面这段代码基本上说清了接口的优点。但是我觉得这代码有错，首先，Cart没有total属性，而且有的话根据我对实体类的了解它应该只能返回实体了的属性，

而不是m_onSale.CalculateTotalPrice(cartItems)。假如就这样吧， total的函数是再BLL.Cart类中实现的，它的具体代码是：

public decimal Total {
            get {
                decimal total = 0;
                foreach (CartItemInfo item in cartItems.Values)
                    total += item.Price * item.Quantity;
                return total;
            }
}

如果网站要扩展的话 ，意思也只能在BLL.Cart中修改了。这个时候好像也只能修改BLL.Cart，至少现在我还想不出别的。

今天我知道了为什么要用接口编程了，说说DALFactory抽象工厂吧。它是先用接口IDAL定义了一序列的规范，然后再用SQLServerDAL里的具体类来实现（如Category），最后在DALFactory抽象工厂中对这些类进行统一的实例化。这样体现了面向接口编程的思想，减少了BLL层对具体某一个类的依赖，实现了松散耦合。