有时候因为种种原因导致我们会写出很多丑陋的代码，比如赶工时，短暂性的偷懒，不会设计模式等等导致代码沉积，一个cs上万行代码这样场景是有发生，

当然这里也包括我。。。所以时间充裕一点之后就想重构一下，毕竟项目中的需求是不断变更的，面对需求变更，尽量做到最低限度的修改代码，最大化的扩充

新代码，还有一点就是不要过分的追求设计模式，做到适可为止，太设计模式了会导致类太多，不好管理，在项目开发中，其实仔细考虑一下，你会发现很多业

务逻辑都有相应的设计模式帮你优化，毕竟这些都是前辈们踩了无数的坑，经过无数的苦难留下来的智慧结晶。很多人列举设计模式都喜欢用生活中的例子，但

毕竟生活中的例子如何应用到项目中，对我们程序员来说还是比较抽象的，所以这里我就列举我们实际的业务逻辑场景。

    我们在做千人千面的时候，为了防止各大邮箱服务商对我们的邮件营销内容做屏蔽处理，我们采用的策略就是众多模板库中随机抽取一封html样式表，然后结

合具体的商品列表生成完全不一样风格的营销内容邮件，争取最大可能的不被屏蔽，而用户自己通过我们系统做的营销邮件，我们又不能随机发送，而是用户生成

什么样的邮件，我们就发什么样的邮件，ok，现在这里就有两种策略场景了，两种场景的最终目的都是生成邮件内容，对吧。

邮件，这种策略没什么好说的，是什么就发什么。

邮件，这种策略采用随机抽取的模式，

目前来说，我们就这两种场景，谁也指不定以后还会不会有其他的策略出来，所以有必要用策略模式玩一下。

    从vs2005开始就有一个强大的功能，根据cs文件自动生成uml类图，非常的直观也更容易的帮助我们设计更加合理的类图。

上面就是策略模式的uml图，各个策略类中都有一个Setup方法，用来设置email的内容，具体各个类中的代码如下：

<1> AbstractStrategy

<2> RandStrategy

<3> StraightStrategy 

<4>StrategyContext

<5> Program

最后我们运行一下：

上面就是一个最简单的策略模式，当我们设置不同的策略，就会执行相应的行为，实际当中，并不会这么简单，毕竟设计模式只是一个最优化的提炼，排除干扰看本质。

   首先生产中我们的AbstractSetup中的Setup方法肯定是要带有参数的，而不是简单的无参，如下：

然后直接赋值的逻辑也非常的简单，需要根据数据库中设置的业务逻辑判断。

接下来就是随机抽取逻辑，这个也是通过读取随机表来进行各种操作，简单的代码如下：

最后就是策略上下文：

好了，这个就是给大家演示的策略模式，简单来说就是一句话：针对同一命令或行为，不同的策略做不同的动作。