《Clean Code》这本书到目前为止一直都在讨论如何编写良好的代码行和代码块。深入研究了函数的恰当构成，以及函数之间如何互相关联。不过，尽管讨论了这么多关于代码语句及由代码语句构成的函数的表达力，除非我们将注意力放到代码组织的更高层面，就始终不能得到整洁的代码。
10.1 类的组织
按照标准的 Java 约定，类应该从一组变量列表开始。如果有公共静态常量，应该先出现。然后是私有静态变量，然后是私有实体变量，最后在变量列表后跟上公共函数。这符合了自顶向下的原则，让程序读起来就像一篇报纸文章。
但是 JavaScript 使用原型继承：每个对象都从原型对象继承属性和方法。原型继承可以模拟经典类继承。为 了将传统的类引入 JavaScript， ES2015 中引入了 class 语法，其底层还是基于原型，只是原型继承的语法糖。
10.2 类应该短小
关于类的第一条规则是类应该短小。第二条规则是还要更短小。
类的名称应当描述清除其权责。实际上，命名正式帮助判断类的长度的第一个手段。如果无法为某个类命以精确的名称，这个类大概就太长了。类名越含混，该类就越有可能拥有过多权责。那么类就不会符合短小的标准。
10.2.1 单一权责原则
单一权责原则（SRP）认为，类或模块应该有且只有一条加以修改的理由。该原则既给出了权责的定义，又是关于类的长度的指导方针。类只应有一个权责--只有一条修改的例由。
系统应该由许多短小的类而不是少量巨大的类组成。每个小类封装一个权责，只有一个修改的原因，并与少数其它类一起协同达成期望的系统行为。
10.2.2 内聚
类应该只有少量变量。类中的每个方法都应该操作一个或者多个这种变量。通常而言，方法操作的变量越多，就越黏聚到类上。如果一个类中的每个变量都被每个方法所使用，则该类具有更大的内聚性。
10.3 为了修改而组织
除了单一权责原则（SRP），其它面向对象设计的关键原则，如开发-闭合原则（OCP）：类应当对扩展开放，对修改封闭，同样重要。
我们希望将系统打造成在添加或者修改特性时尽可能少惹麻烦的架子。在理想系统中，我们通过扩展系统而非修改现有代码来添加新特性。
