设计原则+设计模式：优化代码

思路：首先根据设计原则判断代码的好坏--》根据设计模式的分类--》选择设计模式

设计原则：

单一职责：一个类只负责一个功能领域中的相应职责。高内聚、低耦合。

开闭原则：对扩展开发，对修改关闭。不修改原有代码的情况下进行扩展。

李氏代换原则：所有引用基类（父类）的地方必须能透明地使用其子类对象。

依赖倒转原则：抽象不应该依赖于细节，细节应当依赖于抽象。要针对接口编程，而不是针对实现编程。

接口隔离原则：接口拆分。当一个接口太大时，我们需要将它分割成一些更细小的接口。

迪米特法则：减少依赖。一个软件实体应当尽可能少地与其他实体发生相互作用。

设计模式的分类：

例子：

在一个写业务的类里面:

public void savaOrder(String name){
      //1 创建订单
      System.out.println("创建订单业务逻辑代码！");

    //2 调用接口通知仓库包装
     System.out.println("调用接口通知仓库包装业务逻辑代码！");
   //3 调用物流通知发货
    System.out.println("调用物流通知发货业务逻辑代码！");
}

对照设计原则，一个代码里有多种业务逻辑不符合单一职责，如果现在想加例外一个业务:给用户发短信，那么需要修改saveOrder类，不符合开闭原则。

通过设计原则，已经可以判断这么写代码不怎么好，那么怎么改呢？

首先根据根据设计模式的分类-来选择设计模型的类别：saveOrder不是对象的创建，也不是类与对象的组合，在看saveOrder中每一种业务逻辑都是调用关系（行为），所以选择第三类。

再具体看选择哪一个设计模型：

创建订单后需要调用多种业务逻辑，是一对多的关系，其他业务逻辑都是在创建订单执行之后。对照观察者模式，发现刚刚好。

修改后：

@Autowired
ApplicationContext applicationContext;
public void saveOrder(String name){
    //1创建订单
   System.out.println("创建订单代码！");
//通过Spring发布一个订单创建事件，监听者收到后执行相应逻辑
   applicationContext.publishEvent(new OrderEvent(name));
}

监听者：

public class SmsListener implents SmartApplicationListener{
//收到事件后，执行的业务
public void onApplicationEvent(ApplicationEvent event){
   System.out.println("执行发短信的业务")；
}

public int getOrder(){
//多个监听者，可以定义顺序
return 60;
}

public boolean supportsEventType(Class<? extends ApplicationEvent> eventType){
return eventType==OrderEvent.class;
}
public boolean supportSourceType(Class<?> sourceType){
return true;
}
}