面向对象的魅力

面向对象的魅力

当我想好好聊一聊“面向对象”这种思想的时候，一时还真有点不知道应该从何说起的。

为什么呢？

往小了说，这只是我们在上编程语言课（比如C++,Java）的时候，老师嘴里反复念叨的一个词，我不知道你们当时理解了它的含义没有，我反正是完全不明所以的。

往大了说，我们甚至可以将这个词上升到方法论，甚至是哲学的层面，那就不是在这样的一篇文章内可以讲得完的了。

所以该用什么样的角度来切入呢？我脑海突然里蹦出了”魅力“这个词。没错！当我在用面向对象的思想去想象着软件中的语言，组件，架构，乃至扩展到现实的日月星辰，大千世界的时候，我曾经无数次对这种思想表示惊叹，被她的魅力所深深折服。

既然用到”魅力“这种感性的词，那我们就不贴任何的示例代码，仅仅从抽象的角度聊一聊”面向对象“。

OK，言归正传，首先我们来想一想，软件的作用是到底什么？可能有很多答案，提高工作的效率，比如设计人员用的PS,Final Cut Pro，软件开发人员用到的各种IDE，Tool，又或者行政，财务人员用的Office。满足日常沟通需要，比如微信，微博。再或者提供娱乐消遣，比如魔兽世界，王者荣耀。

然而归根到底，软件的作用只有一个，就是要解决现实问题，没有解决现实问题的软件，是毫无价值的，没有存在的必要。

回想起大学刚上C语言的时候，在实验室用if else，for while写了几个简单的小程序后，我看着屏幕上的这堆字母，心里直犯嘀咕：”这就是程序吗？“因为我想到了给全国人民同时使用的QQ，几十上百万人同时在线的魔兽世界，我无法想象这么庞大的程序，是如何由这么小的代码片段构成的。”肯定有哪里不对！“这就是我当时的想法。（没有任何贬低C语言的意思，C语言无疑是伟大的，而且也可以使用面向对象的思想。只是对当时作为初学者的我来说，能理解指向常量的常指针就不错了，哈哈）

直到后来陆续上了C++，Java课后，开始了解到类，对象，封装，继承，多态等一系列新奇的概念，那感觉就好像打开新世界的大门（面向对象三大特性： 封装，继承，多态）。再后来，我进一步的阅读了设计模式的书籍（如果你还没有阅读过，那么强烈推荐先阅读一下）。对面向对象的理解又有了进一步的加深。

看过书的同学都能说出设计模式有23种模式，设计原则有6条（设计模式六大原则：单一职责原则，开闭原则，里氏替换原则，依赖倒置原则，接口隔离原则，迪米特法则）。为什么会有这些模式和原则？在我看来面向对象思想的学习就像武侠小说里练武功一样。有这么三个层级。拿笑傲江湖里的剑法来举例好了。

第一层：刚学剑的人，会一些普通的剑招，虽然还无法跟真正的高手切磋，但是对付几个市井无赖，地痞流氓应该还是不成问题的。这就像刚熟悉了某一门语言的语法，写几个小程序还是很容易的。

第二层：学会了比较厉害的剑法比如华山剑法，你看还未出华山派时候的令狐冲，作为名门正派的大弟子，用华山剑法教训一下青城派的不肖之徒，给他们来个屁股向后平沙落雁式，还是很easy的。这就像刚熟悉了23种设计模式，可以用单例，工厂，适配器等模式来解决一些实际开发中上的问题（设计模式，模式嘛，顾名思义就是招数，套路）。

第三层：那就是得到了风太师叔的真传独孤九剑，做到手中有剑，心中无剑，无招胜有招。恭喜你，你已经进入绝顶高手之列！这就像是已经完全领会了面向对象的思想，不拘泥于具体的模式，你知道为什么要有类，对象。为什么要有封装，继承，多态。什么是高内聚，低耦合。这无比复杂的现实世界，如何对它们进行抽象，建模，然后映射到虚拟的代码世界中。

这里提到了几个词，抽象，建模，实际上我们编程的过程，也就是将现实的场景和其中需要解决的问题映射到计算机的内存中，然后借助计算机的运算和存储能力，来帮助我们解决这些问题。

首先我们来看看面向对象思想是怎么帮我们进行抽象建模的。

让我们先停下来，在脑海里仔细想一想这个现实的世界是如何运行的，这个大千世界就是由无数的”实体“也就是”对象“组成的，大到浩渺的宇宙星系，小到蚂蚁细菌，原子夸克，都是一个个的对象。这种类繁多的对象，共同构成了我们生活的现实世界。这么复杂的世界如何映射到内存里？答案也很简单，直接把这些对象都映射到内存里去，到这里你可能就明白为什么面向对象里有类和对象的概念了。当然我们不可能把整个现实世界都映射到内存里，我们只是把我们要开发的软件所涉及到的一小部分现实世界抽象进去。毕竟我们不是要开发一个叫做宇宙Online的网络游戏。

那现实的对象如何抽象到内存里呢？我们来思考一下这些对象在现实世界里是个什么样子，每个对象都有自己的属性和行为，属性嘛，比如一个人多高，多重，姓什么，叫什么。行为呢？这个人在这个世界上有些什么活动，起码得吃饭喝水呼吸吧。你会发现，属性都是名词，行为都是动词。其实对象也就这两点，名词的属性，动词的行为。

再来看看面向对象的三大特性。

1.封装：这个好理解，属于某个对象的，就该在某个对象内部，不应该对外暴露，比如二当家的肯定不想让他心肝脾肺肾都被帮主至尊宝看穿，那可就惨了。有的人说我就把属性对外暴露，程序一样跑，有什么必要一定要遵守封装的原则呢？也是，到达目的地的方式可以用走的也可以用爬的，哪种好一些，优雅一些呢？你说对吧。

2.继承，多态，这两个概念其实应该放到一起来说。打个比方我养了一只喵星人，一只汪星人，我要训练他们叫唤，我只关心我发出的命令是”叫一声！“，那么喵星人就应该发出”喵~喵~“的声音，而汪星人是”汪~汪~“，在这里喵星人和汪星人都继承自动物这个类，有”叫一声“的方法。我作为一个调用者，只需要发出让动物叫一声的命令，那么他们自然会叫出不同的声音，这就是多态。这里不是为什么要这样来设计类的继承关系，而是现实世界原本就是按这样的规则在运行的，面向对象的技术只是完美的帮我们解决了如何映射现实世界的问题。

接下来我们再看看设计模式的六大原则。

1.单一职责原则：一个类只负责一个功能领域中的相应职责。想象有一个这样的场景，老板今天把这个同事的工作丢给我做，明天把那个同事的工作也丢给我做，这下我肯定私下要抱怨了，”什么都让我做！我只想做我自己的工作而已，累死了！“。这种心态估计我们都会有吧，那既然我们不想做那些原本不属于我们职责范围的工作，同样的，我们设计的类它也只想做自己职责内的事，如果我们还有其他的工作，就交给其他的类或者再设计一个类吧。

2.开闭原则：一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。这个也好理解，比如我只会蛙泳，当然了，我的蛙泳游得还是挺不错的。这个时候其实我对再学习自由泳是有些兴趣的。但是假如有人跳出来说我的蛙泳姿势这里不对那里不对，要改。那我肯定要心生反感了，我游得好好的，干嘛要改！我对修改关闭，只对扩展开放，我设计的类也是。

3.里氏替换原则：所有引用基类（父类）的地方必须能透明地使用其子类的对象。这句话有点难理解，另一种说法比较简单：在使用继承时，在子类中尽量不要重写和重载父类的非抽象方法。简单来说，父类的抽象方法是让你们子类去各自实现的，但是非抽象方法，实际是父类定下的规范和契约，子类最好都遵守不要修改，否则对整个继承体系是一种破坏。好比一本传承的祖训家规，里面有规定永远不能修改的条目，子孙后代就要无条件遵守。但是里面规定的可以根据时代的不同进行调整的条目，子孙后代就可以具体情况具体对待。

4.依赖倒置原则：抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。这个其实也好理解，想象在一个用人单位中，员工李雷每个月找财务韩MM领工资，但是上个月韩MM离职了，新的财务是Lucy，很显然李雷应该找Lucy领工资。但是如果我们是针对实现编程，那就是李雷永远找韩MM领工资，韩MM可要发飙了，李雷你是傻子吧？我都离职了，还找我要工资？所以应该设计成是员工这个接口找财务这个接口领工资，李雷是员工的实现，韩MM是财务的实现。这样其他的员工Jim也可以找Lucy领工资了。

5.接口隔离原则：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。举个简单的例子，我买了两个多功能的插座，一个用来在书房给需要三孔接口的电脑充电，一个用来在卧室给需要两孔接口的手机充电。我发现这两个插座每个都有几个孔是闲置的，这明显有些浪费。我应该给电脑配一个三孔插座，给手机配一个两孔插座就可以了。当然如果我要在书房同时给电脑和手机充电，那我确实需要一个多功能的插座。当我在程序里设计接口的时候，也是同样的原则。

6.迪米特法则:一个软件实体应当尽可能少地与其他实体发生相互作用。这个也比较好理解。我们都想保持自己在物质和精神上的独立，依赖别人可不是什么好事，毕竟，拿人手短，吃人嘴软。对吧！

最后还有一个疑问，那么在我的软件系统里，我应该设计多少个实体呢？我是把车子设计成一个不可再分割的对象呢？还是应该把发动机，变速箱，车身都设计成对象，然后让他们共同组成车子这个对象呢？答案也很明显，假如我在设计一个汽车销售系统，那么车子是一个对象，我只关心车子的价格，销量。假如我在设计一个汽车维修系统，那么车子肯定是由发动机，变速箱，车身等对象组成。我要关心每个零部件。不然我要不就是过度设计，要不就是毫无扩展性。

永远记住，简单比复杂好，但是也要够用够灵活。

到最后，我们会发现这些原本看起来好像很深奥的概念竟然如此简单？也太容易了吧。哈哈，其实他们原本就是这么的朴实的道理。依据如此简单的原则解决如此复杂的软件设计，这就是面向对象思想的魅力所在！