文章目录
- 引言
- 正文
- 依赖倒转原则
- 工厂方法模式
- 工厂模式的实现
- 简单工厂和工厂方法的对比
- 抽线工厂模式
- 最基本的数据访问程序
- 使用工厂模式实现数据库的访问
- 使用抽象工厂模式的数据访问程序
- 抽象工厂模式的优点和缺点
- 使用反射+抽象工厂的数据访问程序
- 使用反射+配置文件实现数据访问程序
- 单例模式
- 单例模式
- 多线程时的单例
- 双重锁定
- 静态初始化方法
- 面试八股
- 总结
引言
- 踌躇了差不多半天吧,上午写算法一直到一点半,然后的简单做了个饭 ,吃了个饭,两点半了,然后睡了一觉。起来三点钟了,背了二十分钟书,出去拿快递,现在已经四点钟了,才开始一天的工作的,后续还有两件大事,不行,得加快进度。
- 每天哪里在浪费时间呀,早上应该直接把衣服丢到洗衣机里面,然后开始背书,书背完了,直接就能去晾衣服了,然后刷算法那,然后开始补充自己的基础知识。
- 明天再快点好嘛!加油,兄弟,不然照这个进度下去,铁定是要完蛋的。
正文
依赖倒转原则
- 原话:抽象不应该依赖细节,细节应该依赖于抽象的
- 针对接口编程,不要堆实现编程
- 高层模块不应该依赖低层模块,两个都应该依赖抽象
补充—— 里氏代换原则
- 子类必须能够替换掉他们的父类型
- 只有当子类可以替换掉父类,软件单位的功能不受到影响时,父类才能真正的被复用,而子类也可以在父类的基础上增加新的行为
- 由于子类型的可替换性,才使得父类类型的模块在无需修改的情况下,就可以扩展
本质
- 依赖倒转是面向对象设计的标志,编写程序时考虑的是如何针对抽象编程,而不是针对细节编程。
- 程序中所有的依赖关系都终止于抽象类或者接口,这就是面向对象设计。
工厂方法模式
对比简单工厂的实例
- 简单工厂类接受一个标记或者说字符串,然后给出创建好的实例对象,实现对应的功能。
工厂模式的实现
- 下述是工厂类实现的UML图,感觉比较难懂,没看懂
- 对应实现代码
- 加减乘除各建一个具体工厂去实现接口,这些不同运算符的工厂是依赖于具体运算对象
- 客户端实现的方式,通过创建一个加法工厂,然后通过加法工厂,获取对应加法操作对象实例,进行对应操作
简单工厂和工厂方法的对比
简单工厂
- 简单工厂模式的最大优点在于工厂类中包含了必要的逻辑判断,根据客户端的选择条件动态实例化相关的类,对于客户端来说,去除了与具体产品的依赖。
- 如果要对简单工厂类的相关功能进行扩展,除了需要增加相关的操作类,还需要修改工厂类的逻辑
- 违背了:修改封闭的原则,虽然遵循了开放扩展的原则。
工厂模式
- 定义一个用于创建对象的接口,让子类决定实例化哪一个类
- 工厂方法使一个类的实例化延迟到其子类
- 在上面的代码中,这个product就是一个operation对象,然后具体对应到功能,就是返回一个对应的operation子类的对象
- 根据依赖倒转原则
- 把工厂类抽象出一个接口,这个接口只有一个方法,就是创建抽象产品的工厂方法
- 所有要生产具体类的工厂,都去实现这个接口。
- 如果要扩展新的功能,就只需要继承并实现对应的工厂抽象类
将简单工厂模式的工厂类,变成一个工厂抽象接口和多个具体生成对象的工厂,扩展只需要的增加方法类和具体工厂类即可
特点:
- 工厂模式将简单工厂的内部逻辑判断,移到了客户端代码来进行
总结
- 工厂方法克服了简单工厂违背开放-封闭原则的缺点,保持了封装对象创建过程的优点
- 但是并不是最佳,还需要修改客户端的代码,通过反射可以进一步修改
抽线工厂模式
最基本的数据访问程序
- 上述程序的问题
- SqlServer这个具体的数据库对象和用户端高度绑定,如果更换数据库为access,需要修改大量内容,包括客户端的代码已经对应的get方法和insert方法
使用工厂模式实现数据库的访问
- 这里为了降低耦合度,将数据库访问方式和用户端开发进行分离,所以使用工厂方法实现
- 上述是定义了user访问的接口,然后针对不同的数据库定义不同的接口访问类
- 上述是具体的产品类,然后定义相关产品的具体工厂对象
- 客户端只需要根据要求创建对应具体工厂实现类即可。
- 通过上述方式实现业务逻辑和数据访问的解耦,IUser对象就不需要具体知道是什么实现了数据库访问,但是能够很好地完成工作。
使用抽象工厂模式的数据访问程序
- 提供一个创建一系列相关或者相互依赖对象的接口,而无需执行他们具体的类(比起工厂方法,抽象工厂就是涉及到多个product类)
- 针对上述方法抽象工厂模式,用户端在具体使用的时候,创建具体产品类的工厂的concreteFactory,然后通过该具体工厂对象获取对应的产品类productB1和productA1等,实现具体的功能
抽象工厂模式的优点和缺点
-
易于交换产品系列:
- 一个具体的工厂类只需要在初始化的时候出现一次就行,改变一个应用具体的实现类(使用不同的数据库)十分容易,只需要改变具体的工厂就行。
- 既然不能防止需求改变,那就想方设法让需求改变带来的改动最小。
-
让具体的创建实例过程和客户端分离
- 客户端通过抽象接口操作实例,产品的具体类名也被具体的工厂实现分离,不会出现在再客户端你代码中
缺点
- 新增加一个表,需要改的代码太多了,抽象的工厂类以及每一个具体的类,还有对应表格映射类
- 始终无法做到只修改一行语句,就实现替换对应的工厂类
- 上述客户端代码中如果调用了100次new SqlFactory,那么你每一次修改对应的数据库,都要修改一百次这样的语句。
使用反射+抽象工厂的数据访问程序
- 依赖注入(Dependency Injection)和IoC容器管理
反射就是使用字符串变量替换了原来的生成对象的语句,所以以后一旦要修改使用的具体产品工厂,只需要修改这个字符串变量,不需要写对应生成对象的语句,而通过设置配置文件或者全局变量,能够实现只改变一个变量值,替换所有的数据库
- 上述是两种不同的创建工厂的方式,一种是常规方式,另外一种是使用了反射机制,通过字符串变量名来加载对应的工厂实例
- 修改为对应oracle数据访问,就只需要修改对应的变量就行了
使用反射+配置文件实现数据访问程序
- 在简单工厂中使用反射机制来去除switch和if等条件分支语句,降低程序的耦合度。
单例模式
- 将类的构造方法声明为private,让外界无法访问他,也就没有办法构造对应的实例,再写一个共有的方法,调用私有的构造方法,在公有的方法中对类是否存在进行判定。
单例模式
- 保证一个类仅有一个实例,并提供一个访问它的全局访问点
- 主要是让类自身负责保护他的唯一实例,这个类可以保证没有其他实例可以被创建
- 提供一个访问该实例的方法
- 客户端代码
好处 - 保证唯一的实例
- 单例模式封装他唯一的实例,可以严格控制客户怎么样访问它以及何时访问它
- 对唯一实例的受控访问
多线程时的单例
- 多个线程同时访问单例时,会创建多个实例,需要加锁控制
- 因为会有多个线程同时通过判定语句,创建多个实例对象,因为对象不一定存在,所以要额外创建一个实例对象锁。
- 上述方法有问题,就是每一访问,都需要经历一次锁,降低了并发度,影响了性能。
双重锁定
- 使用这种方法只有实例不存在的时候,才会进行加锁判定。
静态初始化方法
-
在类 加载的过程中,就创建了对应的实例,不用再调用的才创建实例
-
饿汉式单例类
- 只有类在被加载的时候,才会将自己实例化,一开始创建的时候就实例化,不需要调用才实例化
- 静态初始化方法,随着类的加载而创建实例,提前占用系统资源,
-
懒汉式单例类
- 要在第一次被引用的时候,才会将自己实例化。
- 不会提前占用系统资源
面试八股
说一说简单工厂模式
工厂方法模式了解吗
抽象工厂模式了解吗
什么是单例模式?单例模式的特点是什么?
单例模式的常见写法有哪些
总结
- 简单工厂模式和工厂模式看了一下,发现确实能够降低代码开发耦合度,以前打比赛的时候,就应该使用这种方法进行开发,不然每一次都需要的给队友好好讲一下代码的逻辑,他要什么,我再给他一个创建一个对象或者接口,最后代码差不多有三千多行,没有意义。
- 今天终于看完了单例模式和工厂模式以及抽象工厂模式,想想当初面试腾讯的时候,我真的是再胡扯蛋,连基本的单例模式都不知道。真的是无语。过不了也是正常地,有没有项目,然后最基本的一些知识点也过不了,难怪哈。
- 题目大概就截了图,明天早上赶早,背一下题目。