一、概念
Spring:三层的核心类都可以使用Spring管理
框架整合:使用Spring整合MyBatis框架
SSH:Spring整合Struct和Heblate框架
SSM:Spring整合mybatis和springMVC(spring的一个模块,不需要整合,只需要整合mybatis,比SSH简单的多)
二、设计模式(背结构)
软件开发经验总结,一类特定问题的解决方案
2.1 单例模式
最简单,只有一个类
2.1.1 使用场景
一个类的对象,在内存中只分配一次
euqals默认还是比地址,想比别的自己去重写
加的锁范围太大了,能锁住,但效果不好
范围弄小,锁不住
双重判断锁
2.1.2 实际应用
实际开发中,自己的项目中,框架,API源码底层,那些地方用过
1.java里的Runtime
2.Servlet:是线程安全的吗
局部变量没有安全问题
3.Spring中的bean默认都是单例的
4.canlendar的构造不是单例的
2.1.3 线程安全
有线程安全:
多线程环境:
共享数据:
多条语句同时修改共享变量:
2.2 简单工厂(23种模式里没有)
违背了开闭原则:
开放:对扩展开放,写好的代码应该运行增加扩展功能
关闭:对修改关闭,写好的代码不能更改(简单工厂增加车的种类,里面增加一条判断,可能会影响之前的代码结构)
2.1 应用场景
改变大量的if判断:用反射加配置文件
配置文件放在项目的根路径下(比放在src下面更快)
new对象很不灵活,会造成耦合;所以用配置文件加反射来解耦
2.2.2 结构
简单工厂做的事太多,违背了功能单一原则
一个父类,若干子类
一个工厂创建所有子类对象
2.3工厂方法
2.3.1 场景
2.3.2结构
一个父类,若干子类
抽象工厂,实体工厂,一个实体工厂创建一类实体产品
将简单工厂里的工厂进行优化,让其出现子类,职责单一,一个子工厂只造一种车
新生产一种车,就新增一个子工厂,看似解耦了,其实还要判断新增什么工厂,还是要用反射加配置文件来解耦
在汽车类里面再写一个简单工厂模式,也可以用type判断,但我们还用反射加配置文件来解耦
2.4抽象工厂
略;自己主动去拓展