设计模式之单例模式和观察者模式

单例模式

定义：确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例

 

单例模式的优势

• 由于只有一个实例，减少了内存开支，特别是一个对象需要频繁地创建、销毁时且进行创建和销毁的性能又无法优化时，该模式具有绝对优势

• 只有一个实例减少了系统的性能开销，当一个对象的产生需要比较多的资源的时候，可以通过在应用启动时直接产生一个单例对象，然后永久驻留内存的方式来解决

• 可以避免对资源的多重占用

• 可以在系统设置全局访问点，优化和共享资源访问

 

单例模式的缺点

• 单例模式一般没有接口，想要扩展很难，一般只能通过修改代码的方式扩展，因为接口对于单例模式没有意义，他的要求就是自动实例化并且提供单一实例

• 对测试不利，对于并发环境来说，如果单例模式并没有完成，不能进行测试

• 单例模式与单一职责原则有冲突，一个类应该只实现一个逻辑，而不关心它是否是单例的，是不是要单例取决于环境，单例模式把“要单例”和业务逻辑融合在了一个类中

 

单例模式的使用场景

• 生成唯一序列号

• 在整个项目中需要一个共享访问点或共享资源

• 创建一个对象需要消耗的资源过多

• 需要定义大量静态常量和静态方法的的环境

 

注意事项

当使用(singleton == null)判断是否创建对象的时候，高并发情况下可能会出现错误，线程A判断为真进行创建对象，线程B判断时A对象为创建成功，同样判断为真创建对象，这样就会出现两个对象（这时推荐使用饿汉式，不推荐懒汉式）

 

 

观察者模式

定义：定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于他的对象都会得到通知并自动更新

 

角色：

Subject(被观察者)：必须能够动态的增加、取消观察者，它一般是抽象类或者是实现类

Observer(观察者)：观察者收到消息后，即进行update，对接收到的信息进行处理

ConcreteSubject(具体的被观察者)：定义被观察者自己的业务逻辑，同时定义对哪些事件进行通知

ConcereObserver( 具体的观察者)：每个观察在接收到消息后的反应不同，各个观察者有自己的处理逻辑

 

优点：

• 观察者和被观察者之间是抽象耦合，这样设计无论是观察者还是被观察者都非常容易扩展

• 建立一套触发机制，观察者模式能完美实现来链式的触发机制

 

缺点：

• 观察者模式需要考虑一下开发效率和运行效率的问题，调试部分也非常麻烦，多级触发更是如此

 

使用场景：

• 关联行为场景，关联行为是可拆分的，而不是“组合”关系

• 事件多级触发场景

• 跨系统的消息交换场景，如消息队列的处理机制

 

注意事项

• 广播链的问题，如果一个观察者即使观察者也是被观察者，那么这个链一旦建立就会特别复杂，可维护性差（所以应该限定消息转发的次数来限定）

• 异步处理的问题，如果观察者比较多，处理时间比较长就使用异步（多线程）