六大设计原则

六大设计原则

---

课程目标

• 学习理解六大设计原则

知识要点

1.单一职责原则（Single Responsibility Principle）

---

	定义：单一模块，单一方法；一个类或者模块只负责完成一个职责。

---

2.里氏替换原则（Liskov Substitution Principle）

---

定义：多用组合，少用继承
理解：子类会继承父类的方法，但是继承是为了实现代码重用，也就是为了共享方法，那么共享的父类方法就应该保持不
变，不能被子类重新定义。而如果需要重新定义共享的方法，最好是在子类里面新增一个方法进行扩展。
这种情况最好使用组合去实现，组合类似与spring的依赖注入的概念@Autowired。自己先实现一个方法类，
注入原先需要继承的类，然后可以直接调用这个需要共享的方法，还可以在新实现类里面进行扩展方法。

public interface ExtendOrderService {
    /**
     * 获取订单信息
     * @return
     */
    String getOrderInfo();
}

/**
 * 本地订单
 */
public class OrderServiceImpl implements OrderService{
    @Override
    public int saveOrder() {
        System.out.println("下单成功，订单号： 888888");
        return 888888;
    }
}

/**
 * 海外订单
 */
public class OutOrderServiceImpl implements OrderService {
    @Override
    public int saveOrder() {
        System.out.println("下单成功，订单号： 66666666");
        return 66666666;
    }
}

public class ExtendOrderServiceImpl extends OrderServiceImpl implements ExtendOrderService{
    @Autowired
    private OrderService orderService;

    @Override
    public int saveOrder() {  //重写父类的保存订单功能
        System.out.println("下单成功，订单号： 1231321323");
        return 0;
    }

    /**
     * 获取订单信息
     * @return
     */
    @Override
    public String getOrderInfo() {  //实现自己的扩展功能
       System.out.println("我是扩展订单信息");
       return null;
    }

    @Test
    public void test(){
        super.saveOrder(); //下单成功，订单号： 888888
        this.saveOrder(); //下单成功，订单号： 1231321323
        orderService=new OutOrderServiceImpl();
        orderService.saveOrder(); //下单成功，订单号： 66666666
        this.getOrderInfo();  //我是扩展订单信息
    }
}

---

3.依赖倒置原则（Dependence Inversion Principle）

---

定义：下层模块引入上层模块的依赖，改变原有自上而下的依赖方向

正常自上而下依赖当我们数据库表字段改变时，可能涉及修改整领域的代码。当从DO层开始倒置依赖entity实体层时，数据库表字段改变我们只需要改对应的实体即可。

4.接口隔离原则（Interface Segregation Principle）

定义：建立单一接口，不要建立臃肿庞大的接口。接口尽量细化，同时接口中的方法尽量少。
理解：
	① 接口要尽量小
			不要违反单一职责原则。
			要适度的小，要适度。
	② 接口要高内聚
		提高接口、类、模块的处理能力，减少对外的交互。
	③ 定制服务
		通过对高质量接口的组装，实现服务的定制化
注意：我理解接口隔离原则是针对接口来说的，而单一职责原则是针对方法/类。

---

5.迪米特法则/最少知识原则（Law of Demeter）

---

定义：只对自己需要耦合或调用的类知道得最少。
理解：：一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂，那是你的事儿，
和我没关系，我就知道你提供的这么多public方法，我就调用这么多，其他的我一概不关心。

---

6.开闭原则（Open Closed Principle）

---

定义：类、方法、模块应该对扩展开放，对修改关闭。
理解：添加一个功能应该是在已有的代码基础上进行扩展，而不是修改已有的代码
注意：这个原则也是需要区分真实业务场景来思考的，例如你只是一个外围系统，新需求需要在原有功能上修改逻辑，那
你可以去新增一个接口，保证原接口的安全，也可以修改原接口逻辑，因为外围系统是需要考虑人力成本以及时间的，再
加上外围系统都是自己内部使用，安全性比较高。如果你是核心系统，那你最好新增一个接口，而不去动原来的接口，
因为你永远也不知道这个接口被外部哪个系统调用，如果遗漏一个系统就是生产事故！！！