设计模式的八个原则:
- 依赖倒置原则:高层次的代码(稳定)不应该依赖低层次的代码(变化),高层次的代码应该依赖于抽象。抽象的代码不应该依赖实现细节,实现细节应该依赖抽象。
- 开放封闭原则:类模块应该开放扩展的,而其原先的代码尽量封闭不可改变。
- 单一职责原则:一个类应该仅有一个变化的原因,该变化隐含了它的职责,职责太多时会导致扩展时对代码东拉西扯,造成混乱。
- 替换原则:子类必须能够替换它的基类(IS-A),继承可以表达类型抽象。
- 接口隔离原则:接口应该小而完备,不该强迫用户使用多余的方法。
- 优先使用组合而不是继承:继承通常会让子类和父类的耦合度增加、组合的方式只要求组件具备良好定义的接口。
- 封装变化点
- 针对接口编程,而不是针对实现编程。
要解决的问题
软件中面临的挑战来自于变化,如各种业务的变化导致我们去不停的修改软件。设计模式就是解决变化的问题,但是要明确的是,设计模式不是让变化消失,而是缩小变化的范围,如一只小猫在满屋子乱跑,会搞得满屋子都很混乱,但是如果将猫关在笼子里,那么混乱只会发生在笼子里,所以设计模式的核心就是把变化关在笼子里,不让变化漫延的到处都是,就可谓好的代码,好的设计。设计模式的要点是“寻找变化点,然后在变化点处应用设计模式,从而来更好地应对需求的变化”.“什么时候、什么地点应用设计模式”比“理解设计模式结构本身”更为重要。
重构的关键技法
静态->动态
早绑定->晚绑定
继承->组合
编译时依赖->运行时依赖
紧耦合->松耦合
设计模式分类
组件协作:
• Template Method
• Observer / Event
• Strategy
单一职责:
• Decorator
• Bridge
对象创建:
• Factory Method
• Abstract Factory
• Prototype
• Builder
对象性能:
• Singleton
• Flyweight
接口隔离:
• Façade
• Proxy
• Mediator
• Adapter
状态变化:
• Memento
• State
数据结构:
• Composite
• Iterator
• Chain of Resposibility
行为变化:
• Command
• Visitor
领域问题:
• Interpreter