设计模式专题00——基础

学习如逆水行舟，不进则退。
在IT这个行业，你不进步就是在退步！

前言：

在面试的时候，面试官常常会问你关于设计模式的东西，有时候，你会觉得好高大上，我这么菜，还不够格去学习吧。
No No No！
其实，很多东西，你平常都用了，只是你不知道而已。
很多人说，设计模式 和 算法一样，属于内功，内功一般无法速成，要多多积累。
本系列专题，就是好好学习设计模式这个东西。
　　
　　　　
　　　　

正文：

什么是设计模式

　　设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。
　　按我的理解，设计模式感觉就像是编程序的时候遵循的一种潜在的规则（潜规则 0 0），让我们的程序更易维护。就像编程时候的命名方式一样，有 匈牙利命名法、骆驼命名法、帕斯卡命名法等，我们可以不遵循它们，但是这样做有可能给你带来困扰。
　　
　　　　
　　

设计模式的一些基本原则

　　设计模式总共有几大基本原则，这些原则都是从这些设计模式中总结出来的，但并不是说所有的设计模式都遵循了这几个原则，而是有些符合，有些不符的情况。这个取舍，取决于你的需求。
　　

单一职责原则

一个类只负责一个领域中的职责
　　作为一个类，还是要专一一些。不要吃着碗里的，看着盆里的，想着锅里的；但你又不能在一棵树上吊死，最终，还是要进行一些取舍。
　　这个原则，其实我们也常常在用，就像我们在编小程序，用到多个函数（在大程序中，可能就是不同的类），我们的函数最常见最普通的会按 输入、输出、逻辑 分开，一个函数负责一个功能。
　　

开闭原则

一个软件实体，应该对 扩展 开放，对 修改 关闭
　　对扩展开放，对修改关闭。行业发展这么迅猛，我们所编写的程序不可能编完后，就一直这么用下去，肯定会随着需求的变化，进行改动、维护、升级。这个原则就是告诉我们，当我们要进行变化时，尽量去扩展，而不是去修改原来的代码。
　　这个原则，尤其是在多人共同工作很好用，因为所有的程序不可能让一个人去完成，所以，主程可以负责主要的逻辑、功能模块的编写及修改，而其他程序员，就可以使用这些模块来实现具体的东西，在实现的过程中，再根据具体情况进行扩展。
　　

里氏代换原则

能用基类的地方，替换成子类也可以继续使用
　　就是我用笔写字，这个笔换成钢笔、铅笔、中性笔都可以。但，反过来，我用铅笔写字，然后可以用橡皮擦来擦掉，不代表你用笔写字，橡皮擦都能擦掉。
　　所以，遵循这个原则，我们其实需要做的就是让子类扩展父类的功能，但不要去修改父类的功能。比如上例，铅笔写出来的字可以擦掉，这是扩展，但铅笔可以写字，并没有改变原有的功能。
　　但，你还可以对原有的功能进行限制，在子类中，对前置条件宽松，对后置返回约束。说人话，就是，我要用笔写字，要写在本上。这是用笔写字的前置条件，但我用中性笔写字，我不限制载体。对后置条件的约束，就是说，我用毛笔写字，必须写一个隶书返回，但对于用笔写字的返回来说，它是不限制字体形式的，幼圆、宋体 随你便。
　　总结起来就是，子类可以扩展父类的功能，但不能修改父类原有的功能；子类重载父类方法时，条件可以宽松一些；但方法的返回值，条件可以更严苛一些。
　　

依赖倒置原则

抽象不应该依赖于细节，细节应该依赖于抽象
　　我们应该是针对接口编程，而不是针对实现来编程。什么是接口，什么又是实现呢？如果我们写超级玛丽这个游戏，我们可以通过方向键来控制 水管大叔 行动。错误的方法就是，编一个键盘控制类，在类中控制大叔移动。这样有什么坏处呢？
　　我们增加一个输入设备，用手柄来控制，不过分吧。再加一个 手柄控制类，在类中控制大叔移动。发现有些不舒服了，有重复工作量，而且，当我改动移动的规则，就要去两个类分别改。这仅仅是两个类，要是再加一个其他类型的控制呢？
　　所以，正确的方法应该是，大叔的移动方法做成一个接口，让各个类去继承，关联。这就是针对接口而非针对实现。
　　

接口隔离原则

使用多个专门的接口，而不适用单一的总接口
　　接口隔离原则，也是很重要的一个原则（总结出来的这些，哪有不重要的呢？）。从简介中也能看出来些眉目，就说现在的手机，能照相、能打电话、能上网… 但是，真的有那么好吗？照相不如相机清楚，打电话不如以前好用，上网速度没电脑快… 最最关键，里面任何一个出问题都可能影响到其他的功能。
　　再到游戏中，做一个人物的动作，比如 攻击、行走、死亡 等，用多个接口来做肯定比一个接口好得多。但我们用多个专门的接口的时候，又要把握好分寸，不要过于细分，过于细化的接口，不仅不方便编写，更不方便管理。
　　

迪米特法则

一个软件实体应该尽可能少的与其他实体发生相互作用
　　这也可以说是最少知识原则，目的就是降低类之间的耦合度。类与类之间的关系越密切，它们的耦合度就越高，灵活性就越差。那么对其中一个类修改，就越复杂。此原则的要点就是降低系统的耦合度，使类与类之间保持松散的耦合关系。
　　迪米特法则还有一种形式，不要和 “陌生对象” 发生交互。除了以下几种，全可归类为陌生对象：
①当前对象本身
②以参数形式传入的对象
③当前对象的成员对象
④当前对象所创建的对象
　　尽量减少对象之间的交互，如果两个对象不必彼此直接通信，那么这两个对象就不要直接去相互交互，如果其中一个对象需要调用另一个对象的某个方法，可以通过第三者转发这个调用，可以通过合理的引用第三者，来降低现有对象之间的耦合度。