程序设计原则
尽量不要让人感到奇怪（不要对这条原则感到奇怪）。
• 使一般问题简单化，罕见问题行得通。
• 一致性（consistency）。这个对我来说已经很清楚，尤其是有了Python以后：如果你强加给程序员越多条条框框，而这些条条框框对于解决手头问题没多大用处，程序员编程的效率就越低。而且这个负面影响不是线性增长的，而是成几何级数增长的。
• 得墨忒耳（Demeter）法则：“不要跟陌生人讲话。”一个对象最好只引用它自己，它自己的属性和它自己方法的参数。
• 减法（Subtraction）原则：当你不能从一个设计里去掉任何东西的时候，这个设计就算完成了。
• 先简单（Simplicity）后通用（generality）（这 是奥卡姆剃刀原则（Occam’s Razor）的另一种说法。它的原话是“最简单的就是最好的”）。一个常见的问题是，许多框架在设计的时候总是一味强调通用性而丝毫没有考虑到实际系统。 这导致一大堆使人眼花缭乱的选项，而这些选项要么经常用不到，要么被误用或者根本就没什么用处。而且，大多数开发人员开发的都是专用系统，很多时候寻求通 用性对他们来说并没有太大用处。寻求通用性最好的做法是通过理解现有的完善成熟的特定例子。因此，这条准则使得在简单设计和通用设计都可行的情况下选择简 单设计。当然，简单设计正好就是一个通用设计也是完全可能的。
• 自反性（Reflexivity）（我推荐这个术语）。每个类一个抽象，每个抽象对应一个类。这个准则也可以称作同构（isomorphism）。
• 独立性（Independence），或者叫正交性（Orthogonality）。独立表达每一个单独的想法。这条准则是分离（Separation），封装（Encapsulation）和模式概念变化（Variation）的补充。它是“低耦合高内聚（Low-Coupling-High-Cohesion）”思想的一部分。
• 一次且只能出现一次（Once and once only）：如果两段代码干的是同一件事情，应该避免逻辑上和结构上的重复。
最初思考这些设计原则的的时候，我只是希望总结出一两条，以便你在分析一个问题的时候直接就能用上。然而，你可以用上面列表里的其它准则作为对照表来检查和分析你的设计。
• 使一般问题简单化，罕见问题行得通。
• 一致性（consistency）。这个对我来说已经很清楚，尤其是有了Python以后：如果你强加给程序员越多条条框框，而这些条条框框对于解决手头问题没多大用处，程序员编程的效率就越低。而且这个负面影响不是线性增长的，而是成几何级数增长的。
• 得墨忒耳（Demeter）法则：“不要跟陌生人讲话。”一个对象最好只引用它自己，它自己的属性和它自己方法的参数。
• 减法（Subtraction）原则：当你不能从一个设计里去掉任何东西的时候，这个设计就算完成了。
• 先简单（Simplicity）后通用（generality）（这 是奥卡姆剃刀原则（Occam’s Razor）的另一种说法。它的原话是“最简单的就是最好的”）。一个常见的问题是，许多框架在设计的时候总是一味强调通用性而丝毫没有考虑到实际系统。 这导致一大堆使人眼花缭乱的选项，而这些选项要么经常用不到，要么被误用或者根本就没什么用处。而且，大多数开发人员开发的都是专用系统，很多时候寻求通 用性对他们来说并没有太大用处。寻求通用性最好的做法是通过理解现有的完善成熟的特定例子。因此，这条准则使得在简单设计和通用设计都可行的情况下选择简 单设计。当然，简单设计正好就是一个通用设计也是完全可能的。
• 自反性（Reflexivity）（我推荐这个术语）。每个类一个抽象，每个抽象对应一个类。这个准则也可以称作同构（isomorphism）。
• 独立性（Independence），或者叫正交性（Orthogonality）。独立表达每一个单独的想法。这条准则是分离（Separation），封装（Encapsulation）和模式概念变化（Variation）的补充。它是“低耦合高内聚（Low-Coupling-High-Cohesion）”思想的一部分。
• 一次且只能出现一次（Once and once only）：如果两段代码干的是同一件事情，应该避免逻辑上和结构上的重复。
最初思考这些设计原则的的时候，我只是希望总结出一两条，以便你在分析一个问题的时候直接就能用上。然而，你可以用上面列表里的其它准则作为对照表来检查和分析你的设计。
