【GeekBand】设计模式1

1.八大设计原则

1.1依赖倒置原则(DIP)–important 贯穿于整个设计原则

高层模块的稳定不依赖于低层模块的变化,两者依赖抽象的稳定
抽象稳定不依赖于细节的变化,实现细节应依赖于抽象的稳定

1.2开放封闭原则(OCP)

对扩展开发,对更改封闭
类模块应该是可扩展的,但是不可修改

1.3单一职责原则(SRP)

一个类应该仅有一个引起它变化的原因
变化的方向隐含着类的责任

1.4Liskov替换原则(LSP)

子类必须能够替换它们的基类(IS-A)
继承表达类型抽象

1.5接口隔离原则(ISP)

不应该强迫客户程序依赖于它们不用的方法
接口应该小而完备

1.6优先使用对象组合,而不是类继承

类继承通常为“白箱复用”,对象组合为“黑箱复用”
继承在某种程度上破坏了封装性,子类父类耦合度高
对象组合只要求被组合的对象有着良好的接口。

1.7封装变化点

1.8针对接口编程,而不是针对实现编程

面向接口设计:接口标准化
将设计原则提升为设计经验:
设计习语 Design Idioms
设计模式 Design Patterns
架构模式 Architectural Patterns

2. 模板方法

2.1概述

定义一个操作中的算法的骨架,而将步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义算法的某些特定步骤。

2.2. 模式中的角色

2.1 抽象类(AbstractClass):实现了模板方法,定义了算法的骨架。

2.2 具体类(ConcreteClass):实现抽象类中的抽象方法,已完成完整的算法。

2.3. 模板方法类图

【GeekBand】设计模式1_第1张图片
Paste_Image.png

3.策略模式

3.1定义

定义一系列算法,把它们一个个封装起来,并且使它们可互相替换。该模式使得算法可以独立于使用它的客户程序而变化。———《设计模式》

3.2结构

【GeekBand】设计模式1_第2张图片
Paste_Image.png

其中Context和Strategy可以在Strategy的子类发生变的时候保持稳定、实现可复用

3.3要点总结

Strategy及其子类为组件提供了一系列可重用的算法,从而使得类型在运行时方便的根据需要在各个算法之间进行切换。

策略模式提供了用条件判断语句以外的另一种选择,消除条件判断语句,就是在解耦合。含有许多条件判断语句的代码通常都需要Strategy模式。

如果Strategy对象没有实例变量,那么各个上下文可以共享同一个Strategy对象,从而节省对象开销。

4.观察者模式

4.1 概述

有时被称作发布/订阅模式,观察者模式定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时,会通知所有观察者对象,使它们能够自动更新自己。

4.2 解决的问题

将一个系统分割成一个一些类相互协作的类有一个不好的副作用,那就是需要维护相关对象间的一致性。我们不希望为了维持一致性而使各类紧密耦合,这样会给维护、扩展和重用都带来不便。观察者就是解决这类的耦合关系的。

4.3 模式中的角色

4.3.1 抽象主题(Subject):它把所有观察者对象的引用保存到一个聚集里,每个主题都可以有任何数量的观察者。抽象主题提供一个接口,可以增加和删除观察者对象。

4.3.2 具体主题(ConcreteSubject):将有关状态存入具体观察者对象;在具体主题内部状态改变时,给所有登记过的观察者发出通知。

4.3.3 抽象观察者(Observer):为所有的具体观察者定义一个接口,在得到主题通知时更新自己。

4.3.4 具体观察者(ConcreteObserver):实现抽象观察者角色所要求的更新接口,以便使本身的状态与主题状态协调。

4.4 观察者模式的类图

【GeekBand】设计模式1_第3张图片
Paste_Image.png

你可能感兴趣的:(【GeekBand】设计模式1)