千万不要学设计模式

一、设计模式有用吗？

我觉得除了方便与他人交流，包括写的代码别人方便阅读或者阅读别人的代码外，其它基本没什么特别用处了。

因为如果你比较菜，而且理解能力一般，经验也浅，你强制学习和使用设计模式，容易误入歧途，生搬硬套，只适合研究和学习一下，能够明白最好，不明白就算了，还不如老实从面向对象分析设计以及UML等基础的东西学起。

但如果你从面向对象以及UML研究起，能够老实研究完一本这样的书，最好有所思考，搜索一些别人关于面向对象设计上的一些细节上的抉择和利弊，也有了一定的编码以及阅读其它别人优秀代码的经历后，特别是你在实际工作中遇到了许多明确的问题，然后能够前期良好的设计或者事后发现了设计上的一些问题和体会，慢慢的你就会发现无所谓设计模式或者不模式，甚至你不停的迭代开发就好，前期代码只能体现基础的功能就好，快速的构建可测试的原型，但你绝对不会把代码“写死”，或者你清楚自己代码的哪些临时的“写死”了，如果你要与他人合作开发，你也能够前期就与他人确立一套“通信”接口和原则等。在不停的迭代开发中，再去完善自己的代码结构也是来的及的。当然前期的代码不单纯指功能，也可能是初步的框架结构。

再者设计模式是对面向对象分析设计时候常见问题的一个最佳实践经验总结，它有它的用处，只当作一个工具来学习使用那是极好的，有胜于无。但实际情况或者说现实世界千变万化，而且错综复杂，哪是23种模式能够概括的，以及复杂度高了后，就是许多模式的嵌套才能解释的通，所以不必太过于纠结：这个是什么模式？这个要用什么模式来解决？这个好像是A模式与B模式的结合等来解释世界。

虽然从单纯的过程式编程过度到面向对象编程时候，人为的把一个系统进行了对象和类的拆分，然后再组合起来，同时由于对象的封闭性，代码的协作分工不同，所以到最后当需要构建更复杂和灵活的系统时候，这种人为的拆分反而让编程失去的灵活性，不可随意写代码了，所以才有了部分解决方案：部分设计模式，的出现，但随着语言本身的发展，一些相应的解决方案都开始固化在语言本身了，或者过于简单，谈不上模式这个称呼。

总结如下：

• 单例模式过于简单，而且属于全局对象，以及考虑释放对象等因素，能不用最好不用。遇到多线程访问时候，互斥也是要考虑的因素。
• 原型模式，本质是个COPY构造过程。
• 其它创建类型模式，工厂方法、抽象工厂、简单工厂、生成器等，都是用一个生产者来生产产品对象，有根据不同类型或者配置参数来生成不同对象的，有根据不同工厂类来生成不同对象的，有根据不同对象类，同时再由这个对象类的不同方法来生产出来最终产品的。还有就是把生产产品对象的这个过程分步进行的封装。大概就是这些不同的创建模式，用UML关系图表达就是Factory与Product之间有一层的关系，这个关系可能是依赖或者关联或者组合等。同时还可以把这层“关系”通过继承继承下来，这样除了继承父类信息外，也继承了这一层“关系”，同时子类的多态性，又可以进行不同的一些变化。其它模式或者说小的程序结构也是类似如此，除了“关系”和“特殊的接口”，就是继承这种“关系”和“接口”等信息，再来个多态。
• 结构性模式如下：适配、桥接、组成、装饰、外观、享元、代理等几个。
          适配比较好理解，当你有两个类接口和交互不匹配的时候，而且这两个类又都是成熟的类，不能随意修改，那中间创建一个适配的类出来，把接口等转换一下就好了。
           其实像组成、装饰、代理，都基本是把其它的类再包装一下，有些用组成关系，有些用关联关系，区别是组成是大量同类对象进行容器化管理；装饰的话，装饰与被装饰的类，是来自同一个父类，同时保持实现的父亲抽象接口一致；而代理的话，主要是要保持与被包装的类的接口完全一致。
            像外观和享元就简单点了，外观只是把一系列动作过程包装成一个，享元只是保持创建的对象列表里面，如果已经创建了对应的对象，就用创建的，如果没有，就创建一个新的，并放入列表，这些好像谈不到模式之说。
• 最后就是行为类型模式：责任链、命令、迭代器、中介者、备忘录、观察者、访问者、策略、状态、模板方法等。
             像备忘录、观察者相对比较简单明了，见到的也比较多，备忘录有点像本地序列化的实现一样，能够保存对象的部分信息，并可以恢复出来。观察者就是个通知回调给观察类。
             迭代器这跟STL里面的一个概念。
              模板方法，跟上面的外观模式处理类似的策略，父类封装许多动作集合为一个动作，然后不同子类实现这些不同的小的动作方法，但总的动作方法不变，使用者统一使用。
               责任链主要是所有同类对象组成一个链，然后把一个动作消息，向链向里传递处理，直到处理完成。
               命令模式和中介者模式，命令模式就是把把个消息动作封装为对象，那这样动作就有了状态和其它信息，能够UNDO/REDO等，消息传递就是选择对应的命令对象就好。中介者模式呢，就是一系统对象之前不直接通信，都关联到一个中间对象来处理，所有信息和处理逻辑就有机会汇集在中介者对象上来了，其它对象信息传递就解耦。
             策略模式和状态模式，策略就是替换一个策略对象或者接口来改变策略动作行为，状态模式类似也是注入一个状态对象，来改变对象的行为表现。
•            

二、不要设计模式怎么办？

有人就会问了：不要去套设计模式来解决遇到的问题，提高代码工程的质量，那构建系统，应该考虑什么呢？

1. 要区分实现者和使用者，即使这些局部性代码全部是写给自己用的，你都要尽量假设这些代码和框架是写给别人用的。这样你就会考虑和注意的多一点，能够区分机制和策略是不同的等。
2. 要区别变与不变的部分，基础功能可能不变，接口可能不变，协议可能不变，框架关系可能不变，其它实现过程基本是会随着需求和其它的因素会变化，同时其实接口和协议，以及框架关系也可能会变，能够抽象到什么合适的层次和粒度，就要看情况了，如果不清楚和不可预见，就适度就好。
3. 高内聚低耦合，这是基本的要求，一定的解耦是必要的，即使短期没有这种需求和好处，但意识到耦合严重，是要随时抽空整理一下的。
4. 面向对象的话，最好每个东西，包括对象和关系是能够解释的，也就是能够用语言表达给别人听，说逻辑是没有意义的。
5. 组件化或者服务化，让部分功能可以单独开发和测试，能够独立运行也可以。虽然运行效率会低一点，即使是这样，我觉得后期稳定了再完整的集成一体，提高运行效率，也算是个好的策略，毕竟开发前期分工多了，集成和测试是个难事，能够先组件服务化，开发稳定了，去掉这层壳，也是可以的。
6. 层次性
7. 迭代，重构，再迭代！许多时候并非你一开始知道所有的模块和业务，而是你慢慢的才知道的。一开始就知道的，那是领域专家，行业专家，比如图像编辑，别人细节清楚，代码工具链丰富，从提出需求，他就知道如何实现了，即使全部用逻辑堆，也能够堆的很完美。但你不是！
8. 要重用别人的封装代码，而不可随意改变它的时候怎么办？即使自己封装的代码和类等，封装的很完整纯粹，也是不可随意改变这种纯粹的，要进行一定的不纯粹改变使用，一样也是要考虑办法解决。
9. 代码量大了，要分工协作怎么拆分，后面能够及时的组装和测试，要如何？
10. 考虑调试
11. 插件化
12. 了解和区分动态和静态，比如动态对象和静态对象。
13. 尽量精通开发语言、数据结构算法、操作系统、网络通信，以及其它相关领域知识和理论，比如图像、音频、机器学习，学习这些比设计模式实用多了，在学的过程中，接触别人的设计和实现，以及体系，迟早你就潜移默化的

所以设计模式基本无用，还是老实写代码，以及研究一下面向对象分析设计相关的资料，能够发现和意识到问题，就离解决问题不远了！