面向对象三大特性：封装/继承/多态。重点再谈谈“封装”

say goodbye to 2021！

不知不觉，2021年在忙忙碌碌中悄然成为历史。在计算机二进制世界，我即将100111岁，多么庞大的一个数字。

回望这一年的工作，还算兢兢业业，在需求开发、系统改造、团队建设方面不断思考，并做成了一些事情。元旦前最后一周也总结并递交了“年度述职报告”。偶尔放空自己，又好像还没做什么，这一年就过去了。新的一年继续加油吧，相信只要用心，时光定不负！

身体是革命的本钱，还是要晒晒这一年里自己的运动战绩。坚持每周跑步25公里的小目标，一年下来完成了1200公里的大目标。这一点，为自己的自律点赞！

 

🍁关于封装，一例以明

 

关于封装，我把经常举的例子再说一下：在一个客户查询页面里有个条件是“客户名称”文本域，按客户名称来模糊查询客户信息，例如，输入“东方”，可以检索到“新东方”、“京东方”、“东方网络科技”这些客户信息。

 

那么，这个需求，我觉得每个开发人员都能实现。并且，我相信，没有一个开发人员会让用户在页面文本框里输入“%东方%”，而是通过SQL的like或者程序的集合操作来实现模糊匹配的功能。

这么一个简单的场景，其实就涉及到封装的理念——程序代码封装模糊查询的功能，用户只需要输入客户名称关键字即可。

为什么这么实现？

出发点有二：1）我们每个开发人员都知道，用户只会输入“东方”这样的关键字，他们不会也不懂“%”是啥玩意儿；2）从系统设计的角度，我们要封装这种模糊查询的逻辑。

 

🍀what is 封装？

我们知道，面向对象程序设计（OOP）有三大特性：封装、继承、多态。在这三大特性中，封装居首位。

坦白说，封装不仅仅是OOP的特性。前端JavaScript脚本里也会封装函数。包括C语言里，也会封装函数。我们的写每一个方法，或者每一个服务类，其实都是封装理论的运用。

封装理解起来容易，程序设计中能真正做好封装，还是蛮考验人的。

分享几个关于封装的例子->100%的人听说过封装，但是80%的人不会封装！

 

🍂关于“封装”的误区

有些开发人员在设计功能时，方法定义得比较随意，比如方法参数是个Map，或者方法是N个String参数，或者返回值是Object或Map，或者方法名与方法逻辑不一致， 当CodeReview过程中大家给出调整建议的时候，这些开发人员会说“这个方法是个私有方法，不会对外访问的”，或者会说“没关系，这个方法只有我在用，不会出问题”，等等。

这些同学，其实是不具备“封装”的理念的。所谓的封装，是对代码职责的封装，我们要站在代码层面来考虑封装，而不是站在“人”的角度。———— 面向对象程序设计（OOD），从这个词汇就可以看出来，要面向“对象”进行抽象和封装，这里的“对象”指的是我们系统的涉众、领域（Business domain），可不是人肉哦。

• 面向对象的封装思维：A代码调用B代码，要考虑B代码的职责完全由B来实现，绝不能出现B实现一部分A实现另一部分的情况。然后，要考虑B怎么暴露API给A代码，如何让A代码明确传递的数据。   
• 面向人肉的“封装”思维：那我就退一步来举例说明一下面向“人”的不良编程思维：A同学的代码调用B同学的代码，B同学草率地提供了API，然后交给A同学，并表示有问题再找自己。B同学的API不明确，文档不清晰，势必会给A同学对接时带来困惑和疑问，A同学可能就要不断询问B同学，或者亲自翻看B同学的代码，然后双方做一些调整，这样交付后免不了会出现BUG。 前面提到的是两位同学，如果API的定义方和调用方是同一位同学呢，即使这种草率的缺乏“设计感”的代码没出现问题，谁又能保证未来的维护过程中不会出现BUG呢？要知道，一个人写的代码并不是永远由这个人来维护哦~
  
• 退一万步，如果要站在人的角度来考虑封装，就请把调用者当成是上面案例中的操作用户，在意识里就别把他们当做可以读代码的开发人员。

 

☘ 接着碎碎念，再列几个关于“封装”的例子

● 退款单退款完成，要把标记原交易订单为已退款。 利用封装来设计程序-> 退款服务提供API：refundSuccess(refundNo)，方法逻辑：修改退款单状态，调用订单服务修改订单状态。

● 订单付款完成，要修改订单状态为终态，然后记账。利用封装来设计程序-> 订单服务提供API：paySuccess(orderNo,status)，方法逻辑：修改订单状态，调用记账服务来记账。

● 假如班级表冗余了学生人数，那么，学生调换班级后，要修改调换前后的两个班级的学生人数。利用封装来设计程序-> 学生服务提供调换班级的API，方法逻辑：修改学生归属的班级，调用班级服务，修改调换前后的两个班级的学生人数。

●