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