日志系统是为运行期提供的,当然一些复杂的调试可能用得上.但日志是要提供有用的信息,而非毫无理由的try catch.try catch往往为了你不能预期且容易出问题的地方存在.
工作如此,同样编码设计亦如此.
当我们在两个或多个地方的时候发现一些相似的代码的时候，我们需要把他们的共性抽象出来形一个唯一的新方法，并且改变现有的地方的代码让他们以一些合适的参数调用这个新的方法。
当业务流程相同,而具体实现 不一致的时候.我们应该面向抽象
DRY 是一个最简单的法则，也是最容易被理解的。但它也可能是最难被应用的（因为要做到这样，我们需要在泛型设计上做相当的努力，这并不是一件容易的事）。它意味着，当我们在两个或多个地方的时候发现一些相似的代码的时候，我们需要把他们的共性抽象出来形一个唯一的新方法，并且改变现有的地方的代码让他们以一些合适的参数调用这个新的方法。
面向接口编程
这是设计模式中最根本的哲学，注重接口，而不是实现，依赖接口，而不是实现。接口是抽象是稳定的，实现则是多种多样的。以后面我们会面向对象的SOLID原则中会提到我们的依赖倒置原则，就是这个原则的的另一种样子。还有一条原则叫 Composition over inheritance（喜欢组合而不是继承），这两条是那23个经典设计模式中的设计原则。
命令-查询分离原则
查询：当一个方法返回一个值来回应一个问题的时候，它就具有查询的性质；
命令：当一个方法要改变对象的状态的时候，它就具有命令的性质；
通常，一个方法可能是纯的Command模式或者是纯的Query模式，或者是两者的混合体。在设计接口时，如果可能，应该尽量使接口单一化，保证方法的行为严格的是命令或者是查询，这样查询方法不会改变对象的状态，没有副作用，而会改变对象的状态的方法不可能有返回值。也就是说：如果我们要问一个问题，那么就不应该影响到它的答案。实际应用，要视具体情况而定，语义的清晰性和使用的简单性之间需要权衡。将Command和Query功能合并入一个方法，方便了客户的使用，但是，降低了清晰性，而且，可能不便于基于断言的程序设计并且需要一个变量来保存查询结果。
在系统设计中，很多系统也是以这样原则设计的，查询的功能和命令功能的系统分离，这样有则于系统性能，也有利于系统的安全性。
1.高内聚， 低耦合
2.依赖倒置原则(核心抽象不考虑具体实现需要什么,而是提供抽象)
3.接口隔离原则(没有关联的接口就不要放一起了)
4.里氏代换原则(子类能够完成父类的业务)
5.开闭原则(对扩展是开放的，而对修改是封闭的。 ) 宁增勿改
6.单一职责远程(一个类，只做一件事，并把这件事做好，其只有一个引起它变化的原因。)
原文：http://www.cnblogs.com/humble/p/3904456.html