开闭原则(OCP)
是一种思想 是我们要写出可维护性的代码 必须要实现的原则
当出现业务逻辑需要修改时 不是在原来的模块或者类或函数上修改 而是重新创建一个新的模块 或者类 或函数 以防出现一些迭代式bug
实现的方式 要面向抽象编程
面向抽象编程
interface abstract
我们要面向抽象编程才能逐步的实现开闭原则
还是要组合使用 这几种模式 Interface abstract => 设计模式 => IOC 和 DI
要做到 开闭原则 就必须做到 调用方法的统一 和对象实例化 的统一
1.Interface 可以统一方法的调用 但是不能统一对象的实例化
面向对象主要就是做两件事 就是 对象的实例化 和方法的调用 （完成业务逻辑）
只有一段代码当中没有出现 new 的出现 才能保持代码的相对稳定性 才能逐步实现 OCP 实质就是 一段代码要保持稳定 就不应该负责对象的实例化
对象的实列化是不可能完全被消除 的 解决的办法就是 把对象的实例化 转移到其他代码块里
Spring Boot 热部署
导入 依赖坐标
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
<scope>runtime</scope>
<optional>true</optional>
</dependency>
去到 设置里 找到 Compiler 把 build project automatically 点上勾 就行了
当我们修改代码时 保存编译后 就会自动重启服务器
常用注解
ResponseBody
自动帮我们解析 返回的对象成json形式
Controller
表示这个是一个控制器 Spring Boot 会帮我们配置
RestController
这个注解包含了 ResponseBoyd 和 Controller 两个注解 可以直接在类上面定义
设计模式
简单的工厂模式 |
确实简单的工厂模式 可以 实现对象的实列统一 我把 在main方法里的对象实列化给 转移的工厂类里 我们只需要在main方法里调用工厂类的静态方法 传入我需要的对象的字符串名 就可拿到 实例化的对象
但是 我们只是保持了main 方法的稳定性 让工厂类里的代码不稳定 在工厂类里面还是需要new 只是把main方法 的 new 转移到了 这里 还有就是 当工厂类的某些方法不是静态的话 在main方法里还是需要new 工厂类出来 调用不是静态的方法
代码中总是会存在不稳定的 隔离这些不稳定 保证其他代码是稳定的
变化造成了不稳定
是什么原因造成了不稳定呢 说白了就是变化 当用户的输入和选择或操作造成了变化 就会发生了不稳定 还有就是我们自身软件的技术需求发生了变化 造成了不稳定
如何解决简单工厂类中的不稳定呢 首先因为是我们之前简单的工厂类的创造对象的方法是 通过接受一个字符串参数 然后通过 switch 的方式进行判断 传进来的参数找对应的分支new对应的对象然后把对象的实例返回去 这样也就是造成不稳定
所以我们可以通过反射来解决这个问题
反射解决不稳定
我们可以在工厂类的方法了 通过
Class<?> cls=class.forname("全类名");//拿到class对象
Object obj=cls.newInstance();//拿到对象的实例
然后把obj对象进行强制转换 在返回去 这样就很好的解决了之前的不稳定
配置文件的变化是不违反OCP 的
IOC DI DIP
DIP 依赖倒置
高层模块不依赖底层模块 两者都应该依赖抽象
抽象不应该依赖细节
细节应该依赖抽象
DI 依赖注入
要实现业务逻辑肯定是各个类之间产生相互的依赖的 之前讲过 我们是不会在 类的内部给他所要依赖的 直接new 出来
我们要通过容器的给这个类注入 这样子代码才会稳定些
注入的方式
1 属性注入 也是set 方法注入
2 构造注入 通过构造器注入
3.接口注入 比较少用
IOC 控制反转
IoC 不是一种技术，只是一种思想，一个重要的面向对象编程的法则，它能指导我们如何设计出松耦合、更优良的程序。传统应用程序都是由我们在类内部主动创建依赖对象，从而导致类与类之间高耦合，难于测试；有了IoC容器后，把创建和查找依赖对象的控制权交给了容器，由容器进行注入组合对象，所以对象与对象之间是 松散耦合，这样也方便测试，利于功能复用，更重要的是使得程序的整个体系结构变得非常灵活。
理解 ： 通过工厂模式 + 反射 +配置 组成一个容器 需要什么就去配置什么 容器根据配置 给我们创建对象 通过依赖注入 注入到对应的类型
