聊聊代码设计的程序解耦

写在前面的话

        我们在程序开发过程中经常会遇到这样的问题：

        我们在开发的中后期，新增、修改需求变得越来越难，因为每一次在原有基础上的新增、修改，都不可避免的接触到旧有代码，而旧有代码在设计之初兵没有考虑太多维护、扩展的问题，这就大大增加了我们的开发成本。诚然，把代码开发到可以运行并不是不能做到，但这相当于变相抛出问题，给后来维护、修改代码的同时挖坑。

        出现这些问题的原因大多是因为代码的：低内聚，高耦合。

        大家都知道代码设计的基本原则是高内聚、低耦合，但代码是一点点完善的，需求是一期期迭代的，很少有人在程序开发之初就做到良好的代码设计，这就导致了很多代码可以运行，但设计上不合理，加大了维护和扩展的难度。

 举一个栗子

        假设需求是这样的：

        1、采购员需要采购一批电脑：当销售状态良好时，我们全量采购，当销售状况一般时，我们折半采购，当仓储清仓时，我们停止采购。

        2、销售员需要销售一批电脑：当库存足够时，我们直接下单，当库存不足时，我们需要先补充库存，然后再下单，当仓储清仓时，我们打折销售。

        3、仓储需要管理一批电脑：我们有增加库存、减少库存、查询仓储的方法给别人调用，我们还要有清仓的业务，当清仓时，我们告诉采购停止采购，我们告诉销售现有库存打折销售。

        这不是一个很复杂的程序代码设计，刚毕业的菜鸟都可以做这样的设计：

        我们创建采购、销售、仓储三个服务类

        采购服务设计如下：

public class Purchase{
    // 仓储对象
    private Stock stock；
   

    // 采购服务
    public void buyComputer(int number){
        // 获取仓储库存
        int stockNumber = stock.getStockNumber();
        // 判断库存，根据剩余库存判断销售状态，采取不同的采购策略
    }

    public void stopBubComputer(){
        // 停止采购
    }
}

          销售服务类如下：

public class Sale{

    // 仓储对象
    private Stock stock;

    // 采购对象
    private Purchase purchase;

    public void saleComputer(int number){

        // 获取仓储信息，如果仓储库存小于订单数量，则采购后再销售，否则直接销售    
    }

    public void offSaleComputer(int number){

        // 打折销售
    }
}

          库存服务类如下：

public class Stock{


    private static STOCK_NUMBER = 100;

    private Purchase purchase；

    private Sale sale;


    // 新增库存
    public void increaseS