100%的人听说过封装，但是80%的人不会封装！（100%的人听说过封装，但是80%的人只会装！）

什么是封装？
概念估计都说不上来了。
只可意会不可言传？

 

好吧，下面3个常见案例，也许会让你加强对“封装”的理解。

 

🌿1. 账户记账

支付系统经常会涉及到记账。记账的目的是管控可用额度，所以，像电商的优惠券、积分等产品，都会涉及到额度控制。
下面是一个简单的场景：
作为灵活用工服务商，商户在我司平台开户后，会向商户账户打款充值，待其项目由平台的自由职业者履约完成后，会将项目的服务费付款给自由职业者。我们约定平台在收到商户打款充值款后向商户收取一定的平台管理费。这个场景下各账户的余额变动是：商户充值后商户账户余额增加，平台服务费户余额增加。付款发起时冻结商户额度，付款成功则进行扣款。
下面两种方式服务交互的方式，涉及到账户接口的两种封装方式，你认为下面哪种更合适？

（设计稿：https://www.processon.com/view/link/611e38c2e0b34d3511f7c479）

  

🍀2. 系统登陆
管理系统登录是最常见的场景了。下面简化场景，用户输入登录口令，点击提交。此时，请求后台接口，做登陆认证和授权。
直接上图。
一个是暴露一个接口，一个是暴露两个接口。如果是你，你更喜欢哪个？

（设计稿：https://www.processon.com/view/link/611e4236e0b34d3511f7d9c2）

 

🍃3. 数据表单提交
数据提交最基本的要求是要对数据做验重判断，当系统里不存在时才做持久化。
如下两种方式，如果是你提供接口，你的选择是？

（设计稿：https://www.processon.com/view/link/611e424b6376894fb728a045）

 

 

以上，你对封装的理解是不是有了更深入的理解？也许你觉得，这些太简单了，肯定知道这些场景的接口怎么封装。你和你所在的团队是幸运的。我表示抱歉，阅读此文浪费了你的宝贵时间。
不过事实也许并非如此。至少，在我们的团队里，类似不良的程序实现还是存在的。当业务发生高频操作时，这些都是隐患。日常开发，还是要关注一下程序设计，多考虑更好的实现方式，磨刀不误砍柴工。