转贴请注明转自：http://blog.csdn.net/gufeng99/article/details/45832711
读程杰的《大话设计模式》有一段时间了，将其C#版的设计模式代码用C++全部重新实现了一遍，并记下个人的一些心得，同时也对一些设计模式进行了改造。网上有份《大话设计模式实现(C++版)》的资料，但稍看后错误不少，比如用作接口的基类不将析构函数申明为虚函数，仅内部使用的成员变量不申明为private（公然违背迪米特法则），new出的对象不进行释放等等一些错误或不良编码习惯，易误导新学C++的同学。故我将我个人实现的C++献丑放出，欢迎大家批评指正，共同进步。
1、单一职责原则
一个类只干一件事情，或者一类事情，功能要单一，就如只有照相功能的照相机，照相的效果肯定牛B过功能齐全的手机。
2、开放——封闭原则
函数、类、模块应该可以扩展，但不可以修改，修改会导致使用它们的老用户无法适应甚至出错。就如国外的大片，本来只有英文字幕，但国内的同学们也要欣赏欣赏腐朽的资本主义文化，但又总不能和老美说：“给哥统统换上中文的，还得加上拼音”（修改），即使老美被伟大的社会主义所震慑，统统换成中文的，但老美的乡亲们估计又要造反了，所以只能靠国内的字幕组同学辛苦辛苦给外挂上中文字幕（扩展），组成大家喜乐见闻的中英文字幕。
微软的windows系统在此法则上就有非常典型的应用，如常用启动进程的API——ShellExecute，因为不能控制启动后的进程，而添加了ShellExecuteEx函数，同时保留ShellExecute给默默做了多年贡献的老同志使用，这样就少了很多的兼容问题。
3、里氏代换原则
子类必须能够替换掉他们的父类，即老鼠的儿子肯定要会打洞，如果不会打洞那就是和隔壁老王生的了。但父类不一定能够替代子类，即儿子学会了调戏猫咪汤姆，但老子见了还是照样得脚底抹油。
4、依赖倒转原则
高层模块不应依赖底层模块，高层和底层都应依赖抽象，针对接口编程，不要对实现编程。面向过程的编程理念中，会有高层依赖底层，但底层不能依赖高层的说法，就是党教育我们的，领导干部（高层）要依靠人民群众（底层）。但面向对象的编程中，就变成了领导干部和人民群众都要依赖于法律（抽象规范），要依法治国。
5、迪米特法则
5.1、每一个类都应该尽量降低成员的访问权限,外界不需要的方法和成员变量都应申明为private。即自己的秘密就让它烂在心里，别一天到晚逮着人就说我有一个大秘密——”我是个傻X“。
5.2、如果2个类不必彼此直接通信，那么这2个类就不应当直接有相互调用或引用，如果确实需要调用，则需通过中间人进行转达。如大家（类1）去发快递，只要把快递给快递公司（中间人）就好了，而不用看那个快递员长得帅就指定那个快递员（类2）帮你去送这封快递。
************************************************************************************************************************************************************
以下是个人总结的一些规则
6、界面和逻辑分离
充气娃娃（逻辑）可以穿女仆装（界面1）装可爱，也可以穿空姐服（界面2）玩制服诱惑，如果无良卖家硬将充气娃娃和女仆装用502粘在一起（界面逻辑合体），估计广大空姐控，护士控屌丝要将差评刷上淘宝首页了。
7、不要将成员变量直接暴露，而通过成员函数来返回或修改
因为类的成员变量是可能会被删除的，同时外部也可直接改动成员变量，造成无法控制的后果。就如开银行，大家要贷款（成员变量：钱），ok，没问题，办贷款手续（成员函数），通过柜台MM把钱给用户。如果大家直接到金库里去拿钱（直接取成员变量），还嚷嚷说哥是来借钱的，估计警察叔叔的子弹会不答应的，即使大家诚实守信，拿了会还，但也总会有人会搬空了金库还拉坨大便改善改善空气。
8、代码重复或改动频繁时，需考虑设计模式
虽然说设计模式好，设计模式棒，但也不是必须天天用，处处使，设计的时候能预计以后需求使用合适的设计模式最好，但若不能，则可先做出demo，在后续需求改变，或代码迭代的过程，如果发现有重复或类似的代码、类或系统频繁的内部改动，则需要考虑设计模式进行重构了。