[面试直通版]设计模式-1-

目录

单例模式

解决问题：

为什么需要单例模式

单例模式的实现方式

建造者模式

解决问题：

为什么需要建造者模式

建造者模式的实现方式

建造者模式的优劣

适配器模式

解决问题：

为什么需要适配器模式

适配器模式的实现方式

适配器模式的优劣

---

• 单例模式

• 解决问题：

• 为什么需要单例模式
• 单例模式的实现方式
• 使用单例模式需要注意的问题

• 为什么需要单例模式

• 对于系统来说，某些类并不需要创建多个实例
• 重复初始化浪费资源
• 如Windows任务管理器
• 多个Windows任务管理器内容完全一致
• 如果多个窗口内容不一致，则问题更加严重
• Windows任务管理器的功能决定了它只能单例呈现
• 即：
• 系统只需要一个实例对象，要求全局唯一
• 类的初始化资源消耗太大而只允许创建一个对象
• 实例只允许使用一个公共访问点，不能通过其他途径访问该实例

• 单例模式的实现方式

• 静态变量:static
• 静态对象获取方法
• 私有构造函数
• 多线程问题
• 多线程调用getInstance函数
• 私有变量重复初始化
• 实现单例模式需要注意多线程的安全问题
• 解决多线程安全问题
• 懒汉模式
• 懒汉模式是指等到需要该对象时才初始化单例对象
• 使用volatile修饰私有变量
• 使用synchronized修饰初始化代码
• 饿汉模式
• 饿汉模式是指提前初始化单例对象
• 相比懒汉模式，实现过程更加简单

• 建造者模式

• 解决问题：

• 为什么需要建造者模式
• 建造者模式的实现方式
• 建造者模式的优劣

• 为什么需要建造者模式

• 可选参数过多的类进行初始化的时候需要很多构造函数
• 这种类不管是在实现还是初始化都比较麻烦
• 当一个类的构造函数参数个数超过4个，而且这些参数有些是可选的参数，考虑使用构造者模式
• 定义：
• 指将一个复杂对象的构造与它的表示分离，使同样的构建过程可以创建不同的表示，这样的设计模式被称为建造者模式
• 它是将一个复杂的对象分解为多个简单的对象，然后一步一步构建而成
• 它将变与不变相分离，即产品的组成部分是不变的，但每一部分是可以灵活选择的

• 建造者模式的实现方式

• 链式调用
• 在开发过程中，经常遇到这种写法，Product product= new builder().setA("fo").setB("bar").setC("so").build();
• 这种写法可以一直.set链式调用，这也是建造者模式的一种写法，通过链式调用去装饰产品，最后build()建造产品

• 建造者模式的优劣

• 优：
• 封装性好，构建和表示分离
• 建造者相对独立，易于扩展，不受被建造类的影响
• 客户端不必知道产品内部组成的细节，建造者可以对创建过程逐步细化，而不对其它模块产生任何影响，建造者使用过程控制粒度更细，便于控制风险
• 劣:
• 实现过程复杂
• 产品的组成部分必须相同，这限制了其使用范围
• 如果产品的内部变化复杂，如果产品内部发生变化，则建造者也要同步修改，后期维护成本较大

• 适配器模式

• 解决问题：

• 为什么需要适配器模式
• 适配器模式的实现方式
• 适配器模式的优劣

• 为什么需要适配器模式

• 定义：
• 将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作
• 为什么：
• 需要开发的具有某种业务功能的组件在现有的组件库中已经存在，但它们与当前系统的接口规范不兼容
• 如果重新开发这些组件成本又很高，这时用适配器模式能很好地解决这些问题

• 适配器模式的实现方式

• 适配器模式有两种实现方式：
• 类适配器和对象适配器
• 类适配器使用继承关系来实现，对象适配器使用组合关系来实现
• 如果Adaptee接口并不多，那两种实现方式都可以
• 如果 Adaptee接口很多，而且Adaptee和ITarget接口定义大部分都相同，那推荐使用类适配器，因为Adaptor复用父类Adaptee的接口，比起对象适配器的实现方式，Adaptor的代码量要少一些
• 如果Adaptee的接口很多，而且Adaptee和ITarget接口定义大部分都不相同，那推荐使用对象适配器，因为组合结构相对于继承更加灵活

• 适配器模式的优劣

• 优：
• 客户端通过适配器可以透明地调用目标接口
• 复用了现存的类，最小程度地修改原有代码而重用现有的类
• 将目标类和适配者类解耦，解决接口不一致的问题
• 劣：
• 增加系统的复杂性
• 增加代码阅读难度，降低代码可读性