第十章 类

第十章 类

10.1 类的组织

• 类的组织应该从一组变量开始；首先是公有静态变量，之后私有静态变量，以及私有实体变量；很少会有公共实体变量；
• 公共函数应该跟在变量之后；
• 公共函数调用的私有工具函数紧随其后；

封装

• 尽可能保持变量和工具函数的私有性；
• 当测试需要访问时，可以将变量和工具函数设为protected属性，方便访问；
• 对于该种变量和工具函数最低要使其为protect或者仅包内可以访问；

10.2 类应该短小

• 类应该短小，权责单一；
• 当不对一个类进行精确命名时，表明该类权责多余一个，而类就太长了；

10.2.1 单一权责原则

• 类或者模块应该有且只有一条修改的理由；
• 再次强调代码能够正常工作不是编码的终点，对其进行组织和重构才是最后一步；
• 对于达到一定规模的系统包含大量的逻辑和复杂性；加以组织就能够方便开发者在哪找到东西和理解需要的东西；

10.2.2 内聚

• 所谓内聚是指类中的方法基本围绕在类的变量进行操作，与外界很少接触；这样的类方法具有高内聚；
• 如果类中变量被每一个方法使用，该类具有最高德内聚性；
• 高内聚表明方法与变量相互依赖，相互结合成一个逻辑整体；

10.2.3 保持内聚性就会得到许多短小的类

• 当存在一个较长的函数时，将函数分节为多个小函数；将原函数中声明的变量提升为实体变量；但这样存在这样的问题，实体变量只被部分方法使用，降低了类的内聚性（理由见上一节）；
• 当内聚点分散时，就是将每个内聚点拆分成一个类；程序会更加有组织，也会拥有更为透明的组织；
• 例程PrimePrinter(素数打印)中，将类分为三个部分；主程序（负责环境搭建）、素数获取、数据输出；

10.3 为了修改而组织

• 对于上述类，当增加一个新方法时需要修改此类；当修改类方法时，需要修改此类；所以权责不单一；
• 解决方法是从每一个方法派生一个类；

• 类的修改与功能增加都互不影响，遵循单一权责原则；
• 此外遵循开放-闭合原则：对扩展开放，对修改封闭；

隔离修改

• 通过抽象类和接口来隔离修改；
• 将外部的细节的不确定性固定在封装的抽象类或者接口中，当细节修改时，直接修改封装，自己的代码不会和细节纠缠在一起；

• 降低链接度，是另一个设计原则，依赖倒置原则（Dependency Inversion Principle，DIP）；类应当依赖于抽象而不是具体细节；