用抽象组件为业务赋能

封装思维，打造业务组件金库

软件工程的精髓之一在于代码的复用。代码复用的好处显而易见，它可以提高开发效率、减少代码量、降低维护成本。

而封装思维正是实现代码复用的关键。封装思维是指将具有相同功能的代码封装成一个独立的单元，然后在需要的时候直接调用这个单元。这样既可以提高代码的可维护性，也可以提高代码的复用性。

现实工作中，许多程序员总是喜欢复制、粘贴自己或他人的代码，而不是提取为组件。项目开始时，这种方式的开发方式比较高效。但当系统慢慢变大时，代码的臃肿与维护成本上升将成为开发者难以承受之重。

而真正优秀的程序员更愿意从庞杂的业务需求中抽象出可以复用的通用组件。因为一个优秀的业务组件设计不仅仅局限于单一的业务需求，它可以被多个业务场景复用。这意味着它具有更广阔的适用范围。

封装的艺术，经验与抽象的碰撞

封装的艺术在于找到合适的抽象层次。抽象层次过高，组件的适用范围就会太窄，导致组件的可复用性降低。抽象层次过低，组件的功能就会太单一，导致组件的可维护性降低。

寻找合适的抽象层次需要经验和抽象能力的结合。

软件工程师在长期编码生涯中，会接触到形形色色的业务，他们从不同的业务需求中锻炼自己的思维方式，沉淀出更加系统的解决问题的办法。最后，这些经验化成一颗颗种子，结成通用组件这朵绚丽的玫瑰。

抽象能力是软件工程师的基本能力。工程师在观察、分析问题后，总能在脑中抽象出严谨、高效、可复用的逻辑思维。然后用正确的编程思想把这个逻辑变为可以复用的代码。

正如伟大的抽象大师爱因斯坦所说：你不可能用创造问题的思维来解决问题。这正是许多刚入行小coder容易犯的一个毛病：过度地依赖已有的解决方案。看到某个业务需求就想复制粘贴过去的经验，不能跳出原有业务场景抽象出通用组件。这是缺少了对通用性需求的抽象思维能力。

封装是上坡路，也是下坡路

封装这条路走得越远，所带来的价值越大。但在抽象的过程中，并不是一帆风顺的。过程中，工程师可能会面临层出不穷的问题。

第一个问题是封装之后的组件的可维护性。组件拆分后的物理结构发生改变，可能更难理解和维护。因此组件的抽象并不仅仅是方法的组合，而是要建立一种低耦合、高内聚的整体结构。这是软件工程师从单点思考到整体设计思考的转变。

第二个问题是组件的使用灵活性。使用灵活的组件需要考虑组件的标准程度、组件之间的兼容性。组件之间的不兼容很容易导致组件的重复。兼容性设计得越好，组件的使用灵活性就越大。工程师设计的组件不仅仅是为了本次业务，还要面向未知，符合通用业务的需求，这样才能为未来的业务服务。

封装是一个上坡路也是一个下坡路，提高的不仅是代码的可维护性、复用性，更是程序员对复杂问题的抽象思维能力。作为一名工程师，应当不断挑战自我，在工作中提升自己的思维层次，磨练自己的技术能力，最终成为业务与技术的粘合剂。