本文为大家介绍软件设计中的一些原则，都是经过长期经验总结出来的知识，每一个程序员都应该了解，相信对大家在进行软件设计的过程中会有很大帮助。

　　Don’t Repeat Yourself (DRY)

　　DRY 是一个简单的法则，也是容易被理解的。但它也可能是难被应用的（因为要做到这样，我们需要在泛型设计上做相当的努力，这并不是一件容易的事）。它意味着，当我们在两个或多个地方的时候发现一些相似的代码的时候，我们需要把他们的共性抽象出来形一个的新方法，并且改变现有的地方的代码让他们以一些合适的参数调用这个新的方法。
参考：http://en.wikipedia.org/wiki/KISS_principle

　　Program to an interface， not an implementation

　　这是设计模式中根本的哲学，注重接口，而不是实现，依赖接口，而不是实现。接口是抽象是稳定的，实现则是多种多样的。以后面我们会面向对象的SOLID原则中会提到我们的依赖倒置原则，是这个原则的的另一种样子。还有一条原则叫 Composition over inheritance（喜欢组合而不是继承），这两条是那23个经典设计模式中的设计原则。

　　Command-Query Separation (CQS) – 命令-查询分离原则

　　查询：当一个方法返回一个值来回应一个问题的时候，它具有查询的性质；

　　命令：当一个方法要改变对象的状态的时候，它具有命令的性质；

　　通常，一个方法可能是纯的Command模式或者是纯的Query模式，或者是两者的混合体。在设计接口时，如果可能，应该尽量使接口单一化，保证方法的行为严格的是命令或者是查询，这样查询方法不会改变对象的状态，没有副作用，而会改变对象的状态的方法不可能有返回值。也是说：如果我们要问一个问题，那么不应该影响到它的答案。实际应用，要视具体情况而定，语义的清晰性和使用的简单性之间需要权衡。将Command和Query功能合并入一个方法，方便了客户的使用，但是，降低了清晰性，而且，可能不便于基于断言的程序设计并且需要一个变量来保存查询结果。

　　在系统设计中，很多系统也是以这样原则设计的，查询的功能和命令功能的系统分离，这样有则于系统性能，也有利于系统的安全性。

　　参考：http://en.wikipedia.org/wiki/Command-query_separation

　　You Ain’t Gonna Need It (YAGNI)

　　这个原则简而言之为——只考虑和设计必须的功能，避免过度设计。只实现目前需要的功能，在以后您需要更多功能时，可以再进行添加。

　　如无必要，勿增复杂性。

　　软件开发先是一场沟通博弈。

　　以前本站有一篇关于过度重构的文章，这个示例是这个原则的反例。而，WebSphere的设计者表示过他过度设计了这个产品。我们的程序员或是架构师在设计系统的时候，会考虑很多扩展性的东西，导致在架构与设计方面使用了大量折衷，后导致项目失败。这是个令人感到讽刺的教训，因为本来希望尽可能延长项目的生命周期，结果反而缩短了生命周期。

　　参考：http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It

　　Law of Demeter – 迪米特法则

　　迪米特法则(Law of Demeter)，又称“少知识原则”（Principle of Least Knowledge），其来源于1987年荷兰大学的一个叫做Demeter的项目。Craig Larman把Law of Demeter又称作“不要和陌生人说话”。在《程序员修炼之道》中讲LoD的那一章叫作“解耦合与迪米特法则”。关于迪米特法则有一些很形象的比喻：

　　如果你想让你的狗跑的话，你会对狗狗说还是对四条狗腿说？

　　如果你去店里买东西，你会把钱交给店员，还是会把钱包交给店员让他自己拿？

　　和狗的四肢说话？让店员自己从钱包里拿钱？这听起来有点荒唐，不过在我们的代码里这几乎是见怪不怪的事情了。

　　对于LoD，正式的表述如下：

　　在《Clean Code》一书中，有一段Apache framework中的一段违反了LoD的代码：

　　final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

　　这么长的一串对其它对象的细节，以及细节的细节，细节的细节的细节……的调用，增加了耦合，使得代码结构复杂、僵化，难以扩展和维护。