专业术语晦涩难懂，特别是当你没有写过稍微大点的系统的时候，你要理解这里面的区别很难。

       从最简单的早期我们学习开始，我们除了练习hello world掌握了入门函数之后，基本都再练习算法。比如水仙花数的获取，冒泡排序，碾转相除法的算法题目，这个时候我们用面向对象来思考，没有太多意义，因为他单纯的只是要解决某个具体的算数层面复杂点。我们大部分情况下，需要的都是推理和算法能力，所以当我们想懂了怎么实现的时候，立刻写几行代码，然后开始run模式，就可以知道我们的想法对了没对。

  更复杂点的工程算法，比如抽奖函数的设计（需要考虑到不同奖品出现不同的概率，而且将不同概率输入该功能函数之后，会返回我们本次的抽奖结果编号），又或者是菜单列表的获取，需要用到递归，读取每个栏目下级的子栏目，同时将这个结果返回给上级结果（递归概念，分类里面最常用的算法），读取文本里面的N行内容，分析提取我们需要的行（简单清洗数据的逻辑）。基本上基础的开发，这些简单算法堆积的时候，发现面向对象毫无优势，甚至是劣势，我为了解答某个题目，脑子里可能出现了N个算法，但是不知道对错，快速写代码跑，直接写肯定比边写还边组织结构要快很多。而且在接入入门早期的时候，我们更倾向于快速实现效果给其他人看，也就是做一个demo的展示产品，这个时候，更快是我们的目标，而对象天然的就增加了这层思考的复杂度。

  于是我们开始操作真正的项目，在真正的项目里面，逻辑链条和关系复杂度比之前的组织几个函数方法完全不同概念，在绝大部分的项目里面，不是算法工程师的话，基本极少用到独自创新的算法，这个时候的工作面临的是无数个模块和函数代码，怎么拼接整理到一起。
最简单的电商产品下单逻辑，我们用流程化的方法来写这个功能。思考的流程是这样的: 我们写个函数

检查商品ID——去数据库查询产品——查询是否下架——查询库存——查询商品其他关联信息——验证登录的用户身份——检查用户——检查用户购买的数量信息——检查用户下单的合法性——.检查优惠券的合法性——计算当前的订单价格——计算订单价格扣除优惠券的计算方法——下单——锁定住优惠券——….

我们将这个流程从头到尾，每一步都实现在一个大型的函数方法里面，洋洋洒洒写了几百行，终于心满意足的感觉完成了这个大型功能。这个时候，需求改了，用户鉴权信息的种类有变更，第二个优惠券可能有很多种，需要重新去N个表里面查询不同的优惠券。过了一阵子，你回头来修改代码，你发现自己密密麻麻的写了一本天书，中间某个地方错误了，你发现不了问题，需要从头到尾一步一步断点打印，而且几乎没有办法的去完善系统。因为出一点问题，要查看自己的一整片代码。

洋洋洒洒写个上几百行代码，封装到一个函数，直接实现了对应功能，感觉上很方便，没有其他的干扰，但是在维护和调试的时候，基本都是瘫痪掉。实在是改不动，如果再碰上别人的代码也是这种风格，逻辑复杂度又很深，基本上就是提桶跑路。接触的几个改不下去的项目，基本都是这种风格，洋洋洒洒，代码堆积在一个方法里面，然后开发不下去了，直接提桶跑路，留给后面的人修改一地鸡毛。这是很典型的面向过程开发者思维，就是以完成过程和实现为核心目标，不考虑后续维护和拓展的开发模式。如果不是刻意去学习对象开发方法，大部分人的第一开发定势都是过程化开发。

而如果是面向对象开始开发，首先我们可以尝试着将上述流程进行对象化处理—— 产品对象，用户对象，优惠券 。
我们使用产品对象的获取方法获取产品（获取失败就退出，那是产品对象出问题了）
同样获取用户对象方法（信息，权限，金额检测）同样失败，退出

优惠券对象方法（检测优惠券的相关信息）

这样我不能再按照之前的的流程化逻辑实现我要的功能，而是设计好一个一个对象，然后我用我的总对象去调用各个对象里面的方法，如果某块出现了问题，我只要直接去调试对应的对象模块即可。

从这里可以很明显的看出俩者的特征，当项目的规模比较小的时候，过程化开发更有优势，因为快速。而面向对象需要不断设计对应的对象，还要梳理结构。

反过来，当项目越来越大的时候，模块不断交叉，对象方法复用度也大幅度提升，对象化开发方法优势非常明显。

而考虑到当前的主要项目，其实一般都是第一期简单，如果有二三四期开发工程的情况，如果你为了快速完成一期使用了过程化开发方法，后面会非常痛苦来调整，所以在一般情况下，大部分项目（除了极少部分你确定知道规模很小的项目）默认采用对象化开发方法，为后期拓展性奠定比较好的基础。