前言
今天码仔没有加班，早早的回到了宽敞且明亮的家里，刚一推开门就听到女朋友的声音：“饭在锅里，我在床上。。。。”
叮铃铃。。。。
好吧，闹钟声不仅打破了清晨的宁静也打破了码仔的美梦。。。程序员还想要女朋友?
但是!码仔心里最不爽的是不仅没有女朋友，每天还要跟不同的“对象”周旋。
程序员的世界里有这么一句话：”万物皆对象“，我们每天都再跟各种”对象“打交道，每天用各种方法来处理“各对象”之间的关系。
码仔就想了，为啥不能把工作中协调”对象“的方法用到自己身上呢?那样自己是不是也能万花从中过了?
说干就干，上方法!
只对自己的女朋友负责 —— 单一责任链
首先在代码界，单一责任链原则的定义是这样的：单一职责原则(Single Responsibility Principle, SRP)：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。它具有高内聚，低耦合的特点。
也就是说，我们在设计类的时候，把实现某类功能的方法，合并到同一个类中，让其只对单一功能负责，这样可以很大程度的减少代码耦合性。例如：我们封装了一个图片处理类用于处理代码中所有图片展示的问题，有圆角显示图片、圆形截取图片、模糊图片等等，到这里都是符合单一责任的原则，这个类只对图片的显示处理负责。但是如果我们再把图片的下载、删除等方法封装进来，这样虽说类的功能更多了，但是其需要负的责任也多了，后期对其的维护和管理更麻烦了。
那这个原则应该如何应用到我们谈对象中呢?其实是一样的，单一责任，只对一个人负责任。我们只需要对自己的“对象”负责任就行了，别人的“对象”不需要你来负责任，你要强行对别人的“对象”负责任，那你大概率会打翻自己对象的醋坛子，然后强行搞崩你们之间脆弱的感情。
一诺千金 —— 开闭原则
我们先看一下开闭原则的定义：开闭原则(Open-Closed Principle, OCP)：一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。也就是说，我们在维护和升级项目的时候，要尽量不去修改已经写好的代码(除非是Bug)通过继承或者别的方式去新增功能。那这个原则又如何运用到我们谈对象当中呢?
两个人交往，肯定少不了一些保证、承诺什么的，对于这些东西一定要牢记，切不可修改。不让会给人家不守信，不靠谱的感觉，当你的女朋友对你有这种认知的时候，那你们的感情大概率要凉了。
分清范围 —— 里氏替换
什么是里氏替换原则呢：里氏代换原则(Liskov Substitution Principle, LSP)：所有引用基类(父类)的地方必须能透明地使用其子类的对象。就是说在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象。这很显然是通过继承思想抽取的方法。那在生活中我们又怎样通过这个方法好好跟对象交往呢?
陪对象一起吃饭也是个很麻烦的事情，因为她总有这些那些不吃的东西。有时候她会明确指出她不吃什么(蒜啊、菠菜啊)但是有时候她会给你一个范围：不吃青菜。如果她给你说的是不吃菠菜，那么她也许会吃生菜或者其他青菜，但是如果她告诉你不吃青菜，你如果还是直男思想的给她吃生菜，还说：“你不是不吃青菜么?这是生菜不是青菜啊!”那你这个脑子还是不用谈恋爱了。
以不变应万变 —— 依赖倒转原则
我们先来认识一下这个原则：依赖倒转原则(Dependency Inversion Principle, DIP)：抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。依赖倒转原则要求我们在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等，而不要用具体类来做这些事情。而我们在实现依赖倒转原则时，通常需要针对抽象层编程，将具体类的对象通过依赖注入(DependencyInjection, DI)的方式注入到其他对象中，依赖注入是指当一个对象要与其他对象发生依赖关系时，通过抽象来注入所依赖的对象。常用的注入方式有三种，分别是：构造注入，设值注入(Setter注入)和接口注入。(依赖注入不仅解耦，还方便单元测试)
恋爱中给女朋友买东西是很麻烦的一件事，因为女人都是善变的。前一秒她还给你说她喜欢这个颜色的口红，下一秒可能就变成了另一个颜色的包包。所以恋爱的时候与其猜来猜去，不如一步到位，直接给钱，以不变应万变，想买什么买什么，方便还省事。(哎!可怜的码仔，为了性福生活只能不断搬砖了)
对症下药——接口隔离原则
这个原则的定义是这样的：接口隔离原则(Interface Segregation Principle, ISP)：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。
接口隔离原则与单一职责原则都是对接口设计的规范。不过，单一职责原则强调的是职责的单一，即业务划分上的单一;接口隔离原则强调的是具体实现时，接口的规模不能过大。比如，一个接口的设计符合单一职责原则，只包含一个职责的定义，但是实现这个职责需要较多的函数或方法，而并不是所有的模块使用此接口时都会用到所有的方法，那么这个接口的设计就不符合接口隔离原则。
不仅在编程中需要接口隔离，谈对象同样也需要 。广大男同胞肯定都有一个通病：对象给你说不舒服，你回复“多喝热水”;对象给你说感冒了，你回复“多喝热水”;对象给你说无聊了，你回复“多喝热水" …… 热水治百病。这样我肯定你活不过三秒。什么药治什么病，对症下药才是王道。
不要到处沾花惹草——迪米特法则
最后一个原则，迪米特法则(Law of Demeter, LoD)：一个软件实体应当尽可能少地与其他实体发生相互作用。迪米特法则还有几种定义形式，包括：不要和“陌生人”说话、只与你的直接朋友通信等，在迪米特法则中，对于一个对象，其朋友包括以下几类：
(1)当前对象本身(this);(2)以参数形式传入到当前对象方法中的对象;(3)当前对象的成员对象;(4)如果当前对象的成员对象是一个集合，那么集合中的元素也都是朋友;(5)当前对象所创建的对象。
任何一个对象，如果满足上面的条件之一，就是当前对象的“朋友”，否则就是“陌生人”。在应用迪米特法则时，一个对象只能与直接朋友发生交互，不要与“陌生人”发生直接交互，这样做可以降低系统的耦合度，一个对象的改变不会给太多其他对象带来影响。
”不要和陌生人说话“，都有对象了还出去沾花惹草肯定是不行的了，毕竟两人恋爱要相互坦诚。只有一心一意想着对方，两人的感情才能长长久久。
总结
以上便是面向“对象”的六大原则。熟练掌握这六大原则不仅能让我们在物质层面更好的满足“对象”(代码都写好了，钞票还远吗?)，还能让“对象”在精神层面满足自己(对象都哄开心了，你离开心还远吗?)。所以无论是为了我们的幸福生活，还是为了我们的性福生活，我们都有必要学习好面向对象。加油吧!骚年
