本文承接上文 使用面向对象重构之-使用接口完成行为抽象。
这次要面对的需求变化是报销流程不仅与员工类别相关，也与报销种类相关，每个报销种类的流程要去不同部门办理，流程差别较大，需要分别扩展。
车费分为打车费和公共交通;打车费需要小票而公共交通则不需要；加班可以报销晚餐；出差的人可以有出差补助，不同城市也有不同的流程。为了让代码体系适应这个需求，就需要引入新的抽象，让代码依赖这个新的抽象体系。


以下代码为之前的实现：

public interface IClaim
    {
        void Claim();
    }


    public class StaffClaimProvider : IClaim
    {
        public void Claim()
        {
            throw new NotImplementedException();
        }
    }


    public class SalesClaimProvider : IClaim
    {
        public void Claim()
        {
            throw new NotImplementedException();
        }
    }

我们只是根据员工种类提供不同报销逻辑的provider，显然已经不够。现在需要进一步对抽象进行调整为：

public interface ITransportClaim{
	void ClaimTransport();	
}
public class TaxiClaimProvider : ITransportClaim{
	public void ClaimTransport(){
		...
	}
}
public class PublicTrafficClaimProvider : ITransportClaim{
	public void ClaimTransport(){
		...
	}
}




public interface IOverTimeFoodClaim{
	void ClaimFood();	
}
public class WorkOverTimeFoodClaimDefaultProvider: IOverTimeFoodClaim{
	public void ClaimFood(){
		...
	}
}
public class WorkOverTimeFoodClaimMidnightProvider: IOverTimeFoodClaim{
	public void ClaimFood(){
		...
	}	
}


public interface ITravelClaim{
	void ClaimTravel();
}
public class TravelSameCountryClaimProvider:ITravelClaim{
	public void ClaimTravel();
}
public interface CrossCountryClaimProvider:ITravelClaim{
	public void ClaimTravel();
}


public class StaffBase{
	...
}
public class LocalStaff :StaffBase{
	public Staff(ITransportClaim transportClaimProvider){
		...
	}
}
public class OTStaff: LocalStaff{
	public class OTStaff(ITransportClaim transportClaimProvider, IOverTimeFoodClaim otClaimProvider): base(transportClaimProvider){
		...		
	}
}
public class TravelStaff :StaffBase{
	public class TravelStaff(ITravelClaim travelClaimProvider){
	
	}
}

接口和类接口基本定义好了。这样就完成了不同报销类别的横向扩展，可是出现了一个问题，staff种类变多了，创建责任就需要统一化，否则对象创建的位置不一，会降低程序的内聚性。这也是Information Expert原则所指出的，信息集中化。下一部分就会着重介绍统一对象创建的位置，以及提高程序内聚性的重要性。
这几个例子是比较极端的需求变更，通常建议project一开始就要规划清楚接口和类的结构，前期需求与代码结构的映射越匹配，所创建的抽象也就越稳定。