java 设计原则(二) 依赖倒置原则

依赖倒置原则

• 定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象

• 抽象不应依赖细节:细节应该以来抽象

• 针对接口编程,不要针对实现编程

• 可以减少类间的耦合性、提高系统的稳定性、提高代码可读性和可维护性，可降低修改程序所造成的的风险。

  假设小明要购买商品 比如零食 衣服 书籍 如下代码实现了这个 功能 但是 如果 此时小明 又要 玩游戏 想要买游戏 那你可得 在在这个类里面写相应的代码逻辑 但后面小明又又叒 要买其他东西了 长期写下去 代码变得越来越长 看起来越来越费劲 当别的小伙伴要帮助小明去实现更强大的能力时 对这个类 修改起来也费劲 。

public class xiaoming1 {
    public  void StudtEnglish(){
        System.out.print("购买零食");
    }
    public  void StudyMath(){
        System.out.print("购买衣服");
    }
    public  void StudyChinese(){
        System.out.print("购买书籍");
    }
}
public static void main(String[] args) {

        gelly g1 = new gelly();
        g1.StudtEnglish();
        g1.StudyMath();
        g1.StudyChinese();
    }

那怎么办呢?
既然都是 在编程里面 抽象 很重要 要把 一些概念抽象出来 然后去写个接口 把要做的事 在接口里面去实现了。既然都是购买书籍 那就把 购买抽象出来把。

//定义一个 抽象接口 购物
public interface shopping {
    //定义买这个行为
    void buy();
}

//实现对买的具体实现
public class buycloth implements shopping {
    @Override
    public void buy() {
    System.out.println("买了衣服");
    }
}


public class xiaoming1 {
    public shopping buy;
    public void setbuy(shopping buy){
        this.buy =buy;
    }
    public void buy(){
        this.buy.buy();
    }
}

    public static void main(String[] args) {
    	//初始化小明
        xiaoming1 xm= new xiaoming1();
        //只要传入要买的 具体实现类
        xm.setbuy(new buycloth());
        //调用实现类
        xm.buy();

    }

这样子的画 如果要扩展 买游戏 那我只要具体写个实现类 高层只要初始化以下 传入进去 进好了。

	//实现对买的具体实现
	public class buyGame implements shopping {
	    @Override
	    public void buy() {
	    System.out.println("买了游戏");
	    }
	}

        xm.setbuy(new buyGame());
        xm.buy();

这样 如果 xiaoming1(高层模块) 添加一些实现 方法 不需要 直接依赖低层次 模块 的方法 简而言之 就是 把易变的具体的东西(低层)的东西 与 那些框架的 抽象的 逻辑抽离开来 这样的话 实现代码的 低耦合 和更稳定。 就像一个 公司 是由 抽象的 战略层 职能层 部门 这样的抽象概念 构成 高层像公司管理层 战略层 他们的改变 的确会影响整个公司 但是具体到 下面的职员(低层模块) 谁离开了 谁又入职了 本质上并不会 影响公司 的正常业务 比如一个企业 如果不设立 部门这种概念抽象的 东西 那 一个boss 对接 到 每一个 下面的职员 是不是 很不方便管理如果底下的员工 都和 boss 这个类直接耦合(就相当于要不断修改boss这个类) 那boss 也就不用干其他事了 光管这些 就 够呛了 。

//公司老大
Boss boss = new boss();
//不直接管理底下职员 应为 底下职员太容易变动了 通过 new 一个 部门经理
boss.setsectorMaster(new sectorMaster());
//通过部门经理 间接管理 底下职员
boss.guanli();

//不直接管理底下职员 应为 底下职员太容易变动了 通过 new 一个 部门经理
boss.setsectorMaster(new HrMaster());
//通过部门经理 间接管理 底下职员
boss.guanli();

这也是 Spring AOP 的历来注入的原理。