模块的设计（书摘）

    模块化的价值毋庸置疑。
    模块化代码的首要特质就是封装。封装良好的模块不会过多向外部披露自身的细节，不会直接调用其它模块的实现码，也不会胡乱共享全局数据。模块之间通过应用 程序编程接口（API）——一组严密、定义良好的程序调用和数据结构来通信。这就是模块化原则的内容。API在模块间扮演双重角色。在实现层面，作为模块 之间的滞塞点（choke point），阻止各自的内部细节被相邻模块知晓；在设计层面，正是API(而不是模块间的实现代码)真正定义了整个体系。
    模块的最佳模块大小，逻辑行在200到400之间，物理行在400到800之间为最佳。模块太小，几乎所有的复杂度都集中在接口，同样不利于理解，也就是透明性的欠缺。
   紧凑性就是一个特性能否装进人脑中的特性。理解紧凑性可以从它的“反面”来理解，紧凑性不等于“薄弱”，如果一个设计构建在易于理解且利于组合的 抽象概念上，则这个系统能在具有非常强大、灵活的功能的同时保持紧凑。紧凑也不等同于“容易学习”：对于某些紧凑 设计而言，在掌握其精妙的内在基础概念模型之前，要理解这个设计相当困难；但一旦理解了这个概念模型，整个视角就会改变，紧凑的奥妙也就十分简单了。紧凑 也不意味着“小巧”。即使一个设计良好的系统，对有经验的用户来说没什么特异之处、“一眼”就能看懂，但仍然可能包含很多部分。
    评测一个API紧凑性的经验法则是：API的入口点通常在7个左右，或者按《代码大全2》的说法，7+2和7-2的范围内。
    如果两个或更多事物中的一个发生变化，不会影响其他事物，这些事物就是正交的。每一个动作只改变一件事，不会影响其他（没有其他副作用）。举个例子，比如读取配置文件，获得系统设置信息这个方法：

module Config
   def self.load_config
         config_str=File.open("r","config.xml").read
         #解析配置文件，可能转化成XML Dom处理等
         
   end
end

  这个方法想当然地认为配置文件存储于磁盘文件中，然而配置文件完全是有可能通过网络获取的，也就是说文件句柄未必来源于磁盘文件，这个方法承担了两个职责：获取配置数据和解析配置数据。重构一下，以提高正交性：

module Config
   def self.load_config(io)
         config_str=io.read
         parse_config(config_str)         
   end
   private
   def self.parse_config(config_str)
    #解析
   end 
end

    这是个小例子，甚至有些不够恰当，用于说明正交性。
    重构技术中的很多坏味道，特别是重复代码，是违反正交性的明显例子，“重构的原则性目标就是提高正交性”。
    DRY（Don't Repeat Yourself)原则，意思是说：任何一个知识点在系统内都应当有一个唯一、明确、权威的表述。这个原则的另一种表述就是所谓SPOT原则（Single Point Of Truth）——真理的单点性。
    提高设计的紧凑性，有一个精妙但强大的方法，就是围绕“解决一个定义明确的问题”的强核心算法组织设计，避免臆断和捏造。