©2020-2024 ioDraw All rights reserved,
Privacy Policy
继续讲程序基础。这一篇主要是介绍面向对象的各种概念性的东西，并不会说具体的代码怎样写，所以可以用一种轻松的心态去看。
一、面向过程和面向对象
面向对象是相对于面向过程的一种编程方式。
面向过程的编程方式由来已久，我刚开始学习Basic和Pascal的时候，都是面向过程的编程方式。这种方式非常的直观，需要写一个功能，直接就写几行实现方法。比如你需要操作一个人移动到某个点，直接就写代码修改一个人的坐标属性，逐格的让他移动到目标点就行了。
面向对象的编程方式，操作的是一个个的对象，比如你还是需要操作一个人的移动，你需要先实例化那个人的一个管理类对象，然后告诉这个“人”的对象，你需要移动到什么地方去。然后人就自己走过去了。至于具体是怎样走的，外部不关心，只有“人”对象本身知道。
面向对象有优点也有缺点，也存在一些争论的地方。确实，面向对象在性能上面肯定不如面向过程好，毕竟面向对象需要实例化对象，需要消耗cpu和内存。但我觉得它的优点也是很明显的，毕竟在一个大型的项目里面，面向对象易于维护和管理，条理也清晰，是一种重要的编程思想。
二、面向对象的4大特征
只要稍微百度一下，就能知道面向对象有4大基本特征：封装、继承、多态、抽象。估计背下来很容易，但实际上它们具体的含义是什么呢？
接下来，我以一家银行为例子，大概说一下我对面向对象这几个特征的理解。
1、封装：
对于一般人来说，银行的印象就只有一排对外办公的窗口，然后有存款和取款2种基本业务。
银行是一个结构非常复杂，功能非常众多的机构。但实际上，我们并不会很关心它的内部是怎样运作的，比如银行的员工是怎样数钱的，怎样记录存款，怎样开保险柜，等等。这些对于外部的人员来说，知道了可能会引起更多不必要的麻烦。所以银行只需要告诉你，你可以在这个窗口办理业务，可以存款和取款，就够了。
所谓的封装，就是指把内部的实现隐藏起来，然后只暴露必要的方法让外部调用。
2、继承：
刚才提到了银行有2种最基本的业务，存款和取款。但现实中，大部分的银行都不止这两种业务，还有很多其他的业务，比如投资窗口、办理对公业务的窗口等等。这些业务，是在最基本的银行存取款业务的基础上再添加的，所以我们可以理解成，基本的银行是只有2种业务的，然后后来的银行在保留了原有银行的业务基础上，再扩展了其他的业务。
如果把基本的银行看做父类（基类），包含存款和取款2个公共方法，那么后来的银行可以看做是子类，它在继承了基本银行存取款的公共方法只后，还自己新增了投资和对公业务两个公共方法。有些银行甚至会重写基本的存取款功能，让自己和基本银行的业务有一定的区别。这个过程，就是继承。
3、多态：
同样是存款的业务，如果我拿着人民币和拿着美元去银行办理，实际上银行处理的方式是不一样的。这种办理同一种业务（公共方法），由于给予的内容（传入的参数类型或者数量）不一样，而导致操作（最终实现的方法）不一样，叫做编译多态，也叫做函数的重载。
接下来，我去了一家银行存款，我不知道这家银行的存款业务有没有和基本银行不一样，反正我就是把钱存进去了，然后具体业务的实现究竟是调用了基本银行存款功能，还是这家银行本身有新的存款功能实现，我是不关心的。这种外部直接调用一个方法接口，然后具体实现的内容由实际处理的类来决定使用基类或者子类的方法，就叫做运行时多态。
4、抽象：
有些观点并没有把抽象列为面向对象的特征。但实际上这是面向对象的一个本质的东西。
虽然银行五花八门，但我们可以找到他们的共性，比如上面说的，基本的银行有存取款业务，投资银行有投资业务，之类，其实就是对银行作出了一个抽象的看法。
在操作的时候，这些业务其实就是一个个的接口，我不管面对的是什么具体的银行，只要是同一个类型的银行，我都可以进行相同的业务办理。
三、面向对象业务的参与角色和边界划分
除了几大特征以外，面向对象在使用的时候有几个概念：参与者、边界、业务主体、业务工人。
这几个概念好像很高端大气，但实际上归纳成一句话，就是“谁做什么，做到什么程度”。
比如“你去银行存钱”，参与人是你自己，业务主体是存钱，业务工人是银行职员，边界就是到存钱为止。
这里的确定边界是一个很重要的概念。面向对象操作的对象实际上是可大可小的，在不同的业务过程里面，参与者和业务的主体是可以改变的的。
还是存钱这件事情，参与者是你自己，但其实包含了一系列后续的操作。比如银行职员在拿到你的钱之后，需要用点钞机去数一下。这个“职员点钞”的过程，实际上是一个子业务，这个业务包含在存款的总业务里面，但是不需要客户去关心。这时候业务的参与者变成了银行职员，业务主体是点钞，业务工人变成了点钞机，业务的边界也只划分到点钞本身。
存款实际上是一个复杂的业务过程，又很多诸如点钞这样的子业务组成了一个大的存款业务，然后如果把存款和取款之类业务看成子业务，这些子业务又组成了银行这个复杂的总业务机构。如果把银行看成是子业务，和商场、市场、交通等子业务，共同的又组成了我们的生活这个更复杂的大业务，把每个人的生活看成是子业务，然后每个人的生活又组成了国家。如此类推，组成了地球、组成了宇宙，无穷无尽……
根据不同的业务边界的划分，我们得到了不同的范围和结果。每一个子的业务，是独立的，我们可以单独的修改它们。比如点钞这个操作，我们可以不用点钞机，改为用手点钞，也能达到同样的结果。再通过一个个子的对象，组合成庞大的复杂的系统。只要我们划分的边界足够的清晰和明确，就可以有条不紊的做各种复杂的功能。这正是面向对象为什么能容易维护和管理的原因。
四、面向对象的一些个人看法
在多年的程序员工作当中，我有幸看到过不少项目的代码，发现有这么一种情况，有些人写程序，喜欢很刻意的去写面向对象，为某些类提取了的基类，提取了很多接口，但到了真正去写实现代码的时候反而不知道该怎样去用这些接口。
也有人问过我，抽象是怎样做到的，比如，他写代码都是按功能先写了类，然后发现类有很多可以重用的地方，再提取成接口，原来的类就变成基类，然后再继承，等等。不是说一般开发都需要围绕接口来开展吗？着好像有点矛盾了。
对于这个问题，我只能谈谈我自己的经验。
按照统一建模语言的理论，其实在实际使用某种语言编写功能之前，应该是有设计阶段的。这个阶段只是弄清楚业务的参与者、边界、业务主体、业务工人等元素，然后归结成“谁做什么”。这个阶段，我们不需要知道是用什么编程语言来实现的，也许根本不需要计算机，用纯人工也能完成功能。
这个阶段也不需要我们知道怎样具体去实现一个功能，只需要知道，我需要在这个范围内实现什么样的几个功能，我需要对外提供什么样的服务让别人使用，就算完成了。然后再下一步，才是讨论使用什么语言来实现，怎样去根据语言的特点去实现。最后才是真正的开始打代码把实现的过程写出来。
针对上面的实现过程，不难发现，其实我们在没有开始写代码之前，我们就已经知道我们需要做什么，需要提供哪一些对外的窗口给别人去用。这些窗口，其实就是抽象出来的接口了。
所以，我自己的习惯是在写任何东西之前，都是先拿笔在纸上面把流程写一遍，把结构搞清楚，把数据的流动过程模拟一下。把思路搞清晰之后，就可以简单的把类的结构写一下，写虚方法，不需要具体实现，只是看看这样的抽象过程有没有问题。如果没问题了，再一个个的把虚方法的具体实现写完整。至于如果需求变动发现之前的抽象不足以应付，可以在有限范围内再进一步的抽象，提取子类，通过多态的方式来实现。