c#设计模式-总结(针对GOF23)

时间:2022-10-01 15:43:02

设计模式的原则?

 

l         单一职责:你不希望因为电脑内存损坏而更换CPU吧,同样也不应该让一个类有多种修改的理由。

l         对扩展开放,对修改封闭:你一定不希望电脑只有一个内存槽,加内存就要换主板吧,程序也应该能在不修改原先程序的情况下就能扩展功能。

l         里氏替换:如果你买的DX9显卡不支持DX9特性,那么这个显卡一定没法用。如果父类的方法在子类中没有实现那就晕了。在程序的世界中千万别认为鸟都会飞,先考虑清楚将会有哪些鸟吧。

l         依赖倒置:针对接口编程,这样即使实现有变也不需要修改外部代码。其实,现在电脑的硬件、网络通讯等都是符合这个原则的,比如USB接口、PCI-E接口、TCP/IP协议。

l         接口隔离:花3000买一个带拍照、听MP3功能的手机还是花1000买一个手机、1000买一个MP3、1000买一个数码相机呢?买了前者的话手机动不动就要修,而且还不一定是因为不能打电话而修,买了后面三样的话即使修也不影响其它使用,你说买哪个?

记得看过一个例子很恰当,说是修电脑比修收音机简单多了。电脑坏了,更换一个零件即可,原因是电脑中的各部分都是基于相对稳定的接口,而且部件各司其职,不会相互影响,电脑本身就是一个非常符合设计原则的产品。收音机的修理没有这么简单了,没有什么部件是插件式的,会修收音机的人肯定明白其中每一个部件的原理。

小程序就好像收音机,确实可以这么做,一共才一个人做的,即使重新做也用不了多少时间。几十个人的大项目如果要改一个需求需要牵涉所有人来修改,那么这个项目用不了多少时间就会因为维护成本太大,维护后BUG太多而报废。

 

比较

 

设计模式

常用程度

适用层次

引入时机

结构复杂度

Abstract Factory

比较常用

应用级

设计时

比较复杂

Builder

一般

代码级

编码时

一般

Factory Method

很常用

代码级

编码时

简单

Prototype

不太常用

应用级

编码时、重构时

比较简单

Singleton

很常用

代码级、应用级

设计时、编码时

简单

Adapter

一般

代码级

重构时

一般

Bridge

一般

代码级

设计时、编码时

一般

Composite

比较常用

代码级

编码时、重构时

比较复杂

Decorator

一般

代码级

重构时

比较复杂

Facade

很常用

应用级、构架级

设计时、编码时

简单

Flyweight

不太常用

代码级、应用级

设计时

一般

Proxy

比较常用

应用级、构架级

设计时、编码时

简单

Chain of Resp.

不太常用

应用级、构架级

设计时、编码时

比较复杂

Command

比较常用

应用级

设计时、编码时

比较简单

Interpreter

不太常用

应用级

设计时

比较复杂

Iterator

一般

代码级、应用级

编码时、重构时

比较简单

Mediator

一般

应用级、构架级

编码时、重构时

一般

Memento

一般

代码级

编码时

比较简单

Observer

比较常用

应用级、构架级

设计时、编码时

比较简单

State

一般

应用级

设计时、编码时

一般

Strategy

比较常用

应用级

设计时

一般

Template Method

很常用

代码级

编码时、重构时

简单

Visitor

一般

应用级

设计时

比较复杂

注:常用程度、适用层次、使用时机等基于自己的理解,结构复杂度基于C#语言,表格中所有内容仅供参考。

 

原则、变化与实现

 

设计模式

变化

实现

体现的原则

Abstract Factory

产品家族的扩展

封装产品族系列内容的创建

开闭原则

Builder

对象组建的变化

封装对象的组建过程

开闭原则

Factory Method

子类的实例化

对象的创建工作延迟到子类

开闭原则

Prototype

实例化的类

封装对原型的拷贝

依赖倒置原则

Singleton

唯一实例

封装对象产生的个数

 

Adapter

对象接口的变化

接口的转换

 

Bridge

对象的多维度变化

分离接口以及实现

开闭原则

Composite

复杂对象接口的统一

统一复杂对象的接口

里氏代换原则

Decorator

对象的组合职责

在稳定接口上扩展

开闭原则

Facade

子系统的高层接口

封装子系统

开闭原则

Flyweight

系统开销的优化

封装对象的获取

 

Proxy

对象访问的变化

封装对象的访问过程

里氏代换原则

Chain of Resp.

对象的请求过程

封装对象的责任范围

 

Command

请求的变化

封装行为对对象

开闭原则

Interpreter

领域问题的变化

封装特定领域的变化

 

Iterator

对象内部集合的变化

封装对象内部集合的使用

单一职责原则

Mediator

对象交互的变化

封装对象间的交互

开闭原则

Memento

状态的辅助保存

封装对象状态的变化

接口隔离原则

Observer

通讯对象的变化

封装对象通知

开闭原则

State

对象状态的变化

封装与状态相关的行为

单一职责原则

Strategy

算法的变化

封装算法

里氏代换原则

Template Method

算法子步骤的变化

封装算法结构

依赖倒置原则

Visitor

对象操作变化

封装对象操作变化

开闭原则

 

 

学习

 

l         掌握设计模式的意图以及解决的问题

l         掌握设计模式所封装的变化点以及优缺点

l         了解设计模式的结构图以及各角色的职责

l         项目中是否应用了设计模式不重要,重要的是设计模式是否正确应用

l         项目中应用的设计模式和GOF设计模式的结构是否一致不重要,重要的是是否从这个结构中得意

l         不管用了还是没有用设计模式,如果违背了原则,就是不恰当的设计

l         没有设计模式是万能的,沉迷于获得一个解决方案的话可能会导致项目结构复杂、代码可读性差、并且造成项目延期

 

结束语

 

l         常用的GOF 23种设计模式介绍完了,这才是起点。

l         本系列文章并没有结束,关注之后非GOF 23种设计模式的相关文章。

l         如果适当运用C# 2.0一些有用的特性(特别是代理、泛型以及分部类和设计模式关联比较大)的话,传统的设计模式有非常大的改进的余地。在实际运用的过程中,优先考虑适用语言特性,如果不行再去考虑适用设计模式。

l         迭代器模式(在C# 2.0中实现非常简单)、解释器模式(应用面非常小,自己也没有整明白)以及备忘录模式(比较简单,没有什么可说的)没有单独立文介绍,但在代码包中包含了相应的例子,所有代码点击这里下载。