设计模式与设计原则
很多人听过设计模式，这是代码编程的最佳实战，是前辈对编写代码的宝贵经验。设计模式就像高级公式，理解复杂，但动手简单，理解了原理和使用方法，即可套用在项目中。假设下面高级公式通过输入 x （面积）即可计算出水的体积 y 。这个公式比较复杂， f(x) 代表简单公式，y = f(x) + 2x + 5 理解需要花费很多精力。设计模式就像高级公式，理解 复杂但运用简单，只需输入 x （面积） 即可得到水的体积。
注意：公式纯属虚构。
而设计原则正好相反，它是设计模式的指导思想，设计原则就像基础公式，理解简单，但动手复杂。下面公式代表 y 与 x 是线性关系，因为公式太抽象，即使理解了原理，也无从下手。设计原则就像简单公式，概念简单但不知如何运用。
如果要排重要程度，个人认为：设计原则 > 设计模式 ，毕竟下层基础决定上层建筑，理解基础公式后，复杂公式可以一步步推导。这两个技能都可以指导我们写出易复用，易扩展的代码，但一般情况下，代码易复用，易扩展都是要牺牲可读性，如果一味的优化代码，会造成晦涩难懂的尴尬境地。在使用设计原则，设计模式之前，一定要避免过渡优化。所谓小赌怡情，大赌伤身。
设计原则学习方法
设计原则分为：SOLID、KISS、YAGNI、DRY、LOD 等，这些字母都是简写，后面会逐一讲解。其实设计原则概念都不难，只要认真读几次，都能看懂。但很多人学个一知半解就去实战，生搬硬套到项目中，最终把项目搞的异常复杂，比如一个简单的用户类根据接口隔离原则各种拆分，虽然提高了可扩展性，但可读性大大降低，相当于你去买菜，本来小推车就可以满足需求，非要研究战斗机。
学习设计原则要多思考少动手，看到一段代码要考虑是否职责过多，使用继承时要考虑确认是否违背迪米特法则，但不要立刻动手，因为代码好与坏非常难衡量。就像书法，有人觉得美妙，有人觉得丑到爆，这就需要持之以恒的思考才能维持这个度。如果你刚学设计原则，避免不了生搬硬套，我刚学的时候也会这样做，但我会思考很久才下手，主要原因有三个：
- 一是因为避免频繁修改代码引来的 bug 。
- 二是因为腐旧代码会依赖非常多的类，冒然修改牵一发而动全身。
- 三是因为第一想法通常不是最好方案，最好方案要经过反复揣摩。
所以我建议初学者要反复思考再下手，思考设计原则就像咀嚼牛皮筋，需要反复咬，如果咬少了，东西不烂不好下咽，如果咬多了，腮帮子又疼。这是个非常有趣的过程，痛并快乐着。
设计模式学习方法
常见的设计模式有 23 种，这里就不列举了。前面讲过，设计模式是编程最佳实战，是大家反复思考+实战，得出比较合适的编程方法。很多人存在错觉，设计模式只支持完美的面向对象编程语言（比如 java ，c++），在其它语言上不能实现，比如在 python 这种对多态，抽象类和接口类支持不好的语言上，就不能实现设计模式。
这句话其实不对， java 语言使用群体较多，语言的历史久远，其教材也就多，但 python 也可以实现设计模式，我在后续的内容会展示 python 的实现方式。其实设计模式的很多方法都可以方便的与面向对象相特性结合，比如利用接口实现工厂类，使用类控制单一实例等等，不得不感叹面向对象语言的优美，但不能完美支持面向对象的语言也可以用设计模式，最初发明设计模式就是无关语言的，这也是它经久不衰的原因。
由于设计模式概念复杂，学习时要先主后深，即先掌握所设计模式每个方法的概念和使用场景后，再深入研究每个设计模式。深入学习后你会发现，在代码层面上，每个模式非常像，很难区分一段代码运用了工厂模式还是策略模式，是桥接模式还是代理模式。只有结合了业务，明白了场景，才会恍然大悟。
所以学习设计模式，可以先搞清概念和使用场景，再深入研究。我开始学习时，一头扎入各种模式不能自拔，想了很久都不明白职责链模式和观察者模式有啥区别，但结合项目后才恍然大悟，原来两个模式的代码本来就差不多，根本没必要纠结代码，理解场景才最重要的。
总结
本篇文章介绍了设计原则和设计模式，讲了学习过程的误区。
- 设计原则：理解复杂，但动手简单，学习时要多思考少动手。
- 设计模式：理解复杂，但动手简单，学习时要先主后深。
设计原则和设计模式用于优化代码，一般情况下，代码易复用，易扩展都是要牺牲可读性，如果一味的优化代码，会造成晦涩难懂的尴尬境地。在使用设计原则，设计模式之前，一定要避免过渡优化。