设计模式（二）—— 技术直男正确“面向对象”的六大原则

前言

从我们开始学习编程便于“对象”结下了不解之缘，老师时常教导我们：“万物皆对象”。在程序的世界中，我们便是主宰，没有女朋友，没事new一个;没有房子，new一个;没有票子，new一个……

作为一名优秀的程序员，肯定少不了“面向对象“，当然这个”对象“不仅仅指的是编程中的对象，还有现实里的对象（程序员还有对象？)。

那应该如何正确的”面向对象“便是我们这篇文章所要讲的。

image

我们为什么要“面向对象”？

身为一名程序员，当你每天晚上拖着疲惫的身体回到家时，是否希望家里有一名娇滴滴的小萝莉在家等着，当你推开门时候对你说：“饭在锅里，我在床上。。。”当然这都是幻想，想要实现这些你需要先有一个女朋友。

如果你满足了这点，你还需要在平时积累在女友心中的好感度。当然，积累平日的好感度也是需要一定方法和技巧的，如果女友心情不好，生病了或者无聊了你给的回复都是“多喝热水”那你们离分手也不远了。所以我们需要学习一些“面向对象”的方法来提高自己的生活质量和精神质量，以便提升自己的性福生活。

为了性福生活

如果你没有女朋友，没关系还有代码“对象”陪你，因为“陪好代码对象”可以提高一个软件系统的可维护性和可复用性，帮助我们设计出更好的程序，拿到更多的奖金，找到更好的“对象”。

综上所述：身为程序员，无论我们有没有对象，为了我们的性福生活，我们都要学好面向对象。面向对象主要有以下六大原则：

一、单一责任链原则 —— 做好自己分内之事

首先在代码界，单一责任链原则的定义是这样的：单一职责原则(Single Responsibility Principle, SRP)：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。它具有高内聚，低耦合的特点。

也就是说，我们在设计类的时候，把实现某类功能的方法，合并到同一个类中，让其只对单一功能负责，这样可以很大程度的减少代码耦合性。例如：我们封装了一个图片处理类用于处理代码中所有图片展示的问题，有圆角显示图片、圆形截取图片、模糊图片等等，到这里都是符合单一责任的原则，这个类只对图片的显示处理负责。但是如果我们再把图片的下载、删除等方法封装进来，这样虽说类的功能更多了，但是其需要负的责任也多了，后期对其的维护和管理更麻烦了。

那这个原则应该如何应用到我们谈对象中呢？其实是一样的，单一责任，只对一个人负责任。意思就是你只需要对自己的“对象”负责任就行了，别人的“对象”不需要你来负责任，你要强行对别人的“对象”负责任有很大概率失去自己的“对象”。

管好自己就行了

二、开闭原则 —— 对扩展开放，对修改关闭

我们先看一下开闭原则的定义：开闭原则(Open-Closed Principle, OCP)：一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。也就是说，我们在维护和升级项目的时候，要尽量不去修改已经写好的代码（除非是Bug）通过继承或者别的方式去新增功能。那这个原则又如何运用到我们谈对象当中呢？

恋爱期间我们肯定少不了送对象礼物，什么生日礼物、七夕节、女生节、儿童节（各种节日）。。。每种节日都要送礼物，如何送一个有特色的礼物呢?我这有个很好的选择——DIY蛋糕，对象生日的时候，带她一起去DIY蛋糕，既能娱乐又有礼物还省钱。而且DIY蛋糕完美的应用了开闭原则：对蛋糕胚封闭，对装饰物开发。每个人提供的蛋糕胚是固定的切不可修改的，但是最终做出来的样式是开放的，每个人的都不一样。所以程序员们，以后实在不知道给对象买什么礼物了就带她去DIY吧，既能娱乐又能学习，一举两得。

image

三、里氏替换原则 —— 有其父必有其子，有其子未必有其父

什么是里氏替换原则呢：里氏代换原则(Liskov Substitution Principle, LSP)：所有引用基类（父类）的地方必须能透明地使用其子类的对象。就是说在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象。这很显然是通过继承思想抽取的方法。那在生活中我们又怎样通过这个方法好好跟对象交往呢？

陪对象一起吃饭也是个很麻烦的事情，因为她总有这些那些不吃的东西。有时候她会明确指出她不吃什么（蒜啊、菠菜啊）但是有时候她会给你一个范围：不吃青菜。如果她给你说的是不吃菠菜，那么她也许会吃生菜或者其他青菜，但是如果她告诉你不吃青菜，那么任凭你把青菜说的天花乱坠你也不可能让她吃一点青色的菜。一定要记清楚对象喜欢吃什么，不喜欢吃什么，不然很容易引发“战争”。

image

四、依赖倒转原则 —— 针对接口编程

我们先来认识一下这个原则：依赖倒转原则(Dependency Inversion Principle, DIP)：抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。依赖倒转原则要求我们在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等，而不要用具体类来做这些事情。 而我们在实现依赖倒转原则时，通常需要针对抽象层编程，将具体类的对象通过依赖注入(DependencyInjection, DI)的方式注入到其他对象中，依赖注入是指当一个对象要与其他对象发生依赖关系时，通过抽象来注入所依赖的对象。常用的注入方式有三种，分别是：**构造注入，设值注入（Setter注入）和接口注入。 **（依赖注入不仅解耦，还方便单元测试）

女人都是善变的，恋爱中的女人更是如此。前一秒还对你说她喜欢这个颜色的口红，下一秒可能就变成了那个颜色的唇釉。所以我们永远不要猜对象到底喜欢什么，直接给钱就完事了，想买什么买什么，方便还省事。（哎，为了性福生活只能不断敲代码）

image

五、接口隔离原则 —— 细化接口职责，留纯除杂

这个原则的定义是这样的：接口隔离原则(Interface Segregation Principle, ISP)：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。意思就是：每一个接口应该承担一种相对独立的角色，不干不该干的事，该干的事都要干。 听起来很像单一责任链原则，其实他们两个可以放到一起理解，只不过一个的对象是类，一个的对象是接口。

不仅在编程中需要接口隔离，谈对象同样也需要 。广大男同胞肯定都有一个通病：对象给你说不舒服，你回复“多喝热水”；对象给你说感冒了，你回复“多喝热水”；对象给你说无聊了，你回复“多喝热水" …… 热水治百病。这样我肯定你活不过三秒。什么药治什么病，对症下药才是王道。

六、迪米特法则 —— 不要和陌生人说话

最后一个原则，迪米特法则(Law of Demeter, LoD)：一个软件实体应当尽可能少地与其他实体发生相互作用。迪米特法则还有几种定义形式，包括：不要和“陌生人”说话、只与你的直接朋友通信等，在迪米特法则中，对于一个对象，其朋友包括以下几类：
(1)当前对象本身(this)；
(2)以参数形式传入到当前对象方法中的对象；
(3)当前对象的成员对象；
(4)如果当前对象的成员对象是一个集合，那么集合中的元素也都是朋友；
(5)当前对象所创建的对象。
任何一个对象，如果满足上面的条件之一，就是当前对象的“朋友”，否则就是“陌生人”。在应用迪米特法则时，一个对象只能与直接朋友发生交互，不要与“陌生人”发生直接交互，这样做可以降低系统的耦合度，一个对象的改变不会给太多其他对象带来影响。

”不要和陌生人说话“，都有对象了还出去沾花惹草肯定是不行的了，毕竟两人恋爱要相互坦诚。只有一心一意想着对方，两人的感情才能长长久久。

image

设计模式目录

设计模式（一）—— 认识设计模式
设计模式（二）—— 技术直男正确“面向对象”的六大原则
设计模式（三）—— 单例模式
设计模式（四）—— 原型模式
设计模式（五）—— 简单工厂模式

总结

以上便是面向“对象”的六大原则。熟练掌握这六大原则不仅能让我们在物质层面更好的满足“对象”（代码都写好了，钞票还远吗？），还能让“对象”在精神层面满足自己（对象都哄开心了，你离开心还远吗？）。所以无论是为了我们的幸福生活，还是为了我们的性福生活，我们都有必要学习好面向对象。加油吧！骚年！

image