设计模式-算法模式

C# 设计模式

最近开始看Head First 设计模式这本书

里面的语法使用的是JAVA，与最近专案用的C#两者大概有87% 像

刚好来补充一下这方面的知识

也顺便写篇文章纪录一下

第一章 策略模式 Strategy Pattern

先给书中对策略模式的定义:

定义了算法族
将不同算法分别封装起来
此模式让算法的变化独立于使用算法的客户端外
所以不同算法间，可以互相替换

书中的场景:

主体是各种鸭子，会有不同的

                  外型

                  飞行的行为    

                  发出声音的行为

主角将不同类型的鸭子里面

   各自实践 不同的飞行的行为  

                         不同的发声的行为  

                         不同的外表与颜色

当遇到需求修改时 不仅要修改具体行为 可能还得修改使用这些具体行为的鸭子的相关实践

且重复的代码多

思绪:

将程式 不会变化的 跟 一直变化的部分 分开来

将常常变化的部分封装起来 让他不要影响其他的(省去未来的Loading)

所以将

不同的”飞行” 的 行为们 独立成 一组 有飞行的算法库

不同的”声音” 的 行为们 独立成 一组 有声音的算法库

不同的”外表” 的 行为们 独立成 一组 有外表的算法库

场景对照:

    客户端 use 算法

鸭子的外表 use “外表”算法库的其中一种

鸭子的声音 use “声音”算法库的其中一种

同一类的有一组行为 SET ，让客户端要拥有这一类的行为时 可以从这个set中挑选

为了避免每次新增需求就要修改客户端的代码，改成新增算法到算法库

逻辑 原则 流程

分析出 改变的地方 把他独立出来

让你能动态抽换

这本书讲设计模式时，会反覆的提到了他的思考方式，也就是四人帮提出的的设计原则

其中提到了

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

我想将这段话对应到 这个模式

看了好几次，每次都很模糊，最后有些了解分析如下

调用这个模式的是你的客户端，他是这句的主词



"客户端"针对接口编程,而不是针对实现编程

当你的主程式要用 这个东西时 你是用一个参照 也就是reference 或是接口

所以把有变化要被主程式调用的 算法或是程式逻辑的实践 隐藏在接口后面

客户端自己的的代码流程中 “算法” 是以接口的行式去参与的

不是依据你的代码，而是隔着接口

使用模式开发的流程如下:

宣告一个 某类行为的接口

客户端可以调用这个接口去实践

接口后面就是选择 你要使用哪种这类行为的实践

好处:

接口使用哪种具体实践 很具有弹性

甚至可以动态切换

可以参考底下的 UML

图片来源: O’Reilly C# 3.0 Design Patterns