我所认识的软件开发原则：封装

      在Google搜索封装，给出信息隐藏这样的一个概念。把复杂度隐藏于实体内部，对外提供简单，精练的访问接口。这个原则普遍存在于现实生活中，在软件开发领域也始终提倡着。Java向来倡导程序封装，面向接口编程，以提高工程开发和维护效率。

      说到封装，让我想起大四的一次面试经历。面试官抛出的惟一与技术有关的一个问题是：你觉着面向对象思想的特点中，哪个特点是最重要的？ 以当时熟背面向对象思想，写过两三天Java程序的经验，我很郑重地回答：封装。之后这次不成功的面试经历留给我最大的疑问就是，难道封装不是最重要的么？

      当然什么是面向对象思想最重要的特点，以当年浅显的认识是不敢再去探究的。时至今日，也不敢对当初的问题做出肯定的回答，但这个简单有效的原则在软件设计和开发过程中所使用的频度，很明显地确立着它的重要性。

      日常开发中，频繁使用接口对调用者隐藏逻辑实现。就是在自己的具体实现中，模块与模块之间做到有序封装，这种思想可以体现在最基础的那个方法或是那行代码上。例如提供时间格式转换的类，与调用者之间的联系就是你给我时间等参数，我给你正确的时间格式。至于具体怎样实现，调用者不需要关注。

      从最底层的逻辑实现到中层的数据包装，再到高层的服务，层与层之间的关系变得简单明了。OSI七层协议是最好的例子，每层只关注自己在数据交换中所扮演的角色：包装上层传入的数据；对从下层接收到的数据做解包装。研究网络不同领域的技术人员只专注于不同的处理层，对于每层逻辑实现的变更，不会影响与其它层的数据传输接口。
     

      对于这样的成功的例子可以列举出很多，但它们遵循的封装原则是类似的。这些例子的殊途同归预示着我们可以总结出运用封装原则的一些基本点。下面就我最关心的一个问题做初步的分析。

什么时候开始封装：
   

• 模块之间逻辑纠缠不清：这种纠缠小到底层实现，大到系统与系统，网络与网络的交互。 在代码实现层面，我们一般使用代码结构化封装，如类与方法。类处理自己分摊到的系统职责，管理一系列与职责相关的具体实现。方法独立或与其它方法配合完成任务，方法间做到责任明确，协作简单。在模块层面，各模块管理众多类来完成较大任务，也需要保持独立，简洁的数据传递。当然正常情况下这种模块间的交互不是很复杂。在这里就可以采用很多设计模式提高代码的结构与表达能力。在更高层，系统或网络之间，我们必须保证不能有复杂的逻辑交互，因为有网络带宽，系统负载等条件的影响。系统之间可以传输简单有效的数据。可以在响应时间，处理效率上做出让步。
• 责任划分：正常情况下，系统或模块有众多人员开发维护。对模块的封装，有利于每个人理清自己的责任。
• 安全考量：对于有些涉及安全问题的模块，如权限或机密业务数据，单独开发维护，只对外提供基本的服务。
• 发挥专业性：每个人所擅长的领域不一样，在模块封装时就可以考虑把合适的事情交给最擅长的人去做。比如项目需考虑业务处理时效率，就可以编程语言来划分不同的模块达到有效交互的目的。
• 降低使用复杂度：用户始终需要最简洁方便的交互。一个只会QQ聊天的用户只应该觉着上网如此简单，而不在乎这个东西到底是多么的纷繁复杂。程序与程序之间，暴露过多内部实现细节，会让调用者无比困惑。

      上面说了太多封装原则的好处，至少让我觉的，这个简单的原则可以适用于任何地方。就是非要找它的缺点，以我的理解应该有这样一些方面：
  

• 增加学习成本：对于想了解系统或模块具体业务实现的人来说，层层封装显得过于封闭。爱因斯坦拆闹钟的时候也许非常急躁吧。
• 封装的异常情况：把台灯插到插座上没亮，经过很多测试，得出是插座的问题。那到底是插座里面的线断掉了还是插座的接线断掉了，无从得知。模块接收到调用者的请求后如果没法处理数据，应该怎么办?把任务抛弃什么也不做，还是返回错误状态告诉调用者这里出错了。这些错误情况的处理方式 对于调用者来说有着很大的区别。如果能返回正确有错误状态，那么调用者就可以做相应的异常处理机制。否则会很莫名，只有千万百计深入到模块内部查看问题。

      其实呢，对于这样一个普遍的原则，过多的解释和定义是不恰当的，有引简为繁的误解。但归根结底，我想表述的是这种原则的重要性。无论在是生活还是在编码中，处处可见它的身影，让我体会到很多益处。物极必反，过多使用封装也有增加程序的复杂度。



我所认识的软件开发原则：权衡
我所认识的软件开发原则：简单表述
我所认识的软件开发原则：二八原则
我所认识的软件开发原则：减少等待时间