设计三大原则：
DRY： Don't Repeat Yourself。这条准则是 不要重复你自身 。尽量在项目中减少重复的代码行，重复的方法，重复的模块。其实许多设计原则和模式最本质的思想都是在消除重复。我们经常提起的重用性和可维护性其实是基于减少重复这一简单的思想。有效的防止了“ 散弹式修改” -- 由于代码重复而导致一个小小的改动，会牵扯很多地方。
KISS：这条准则是 保持简单易懂 。从小到几行代码的写法大到整个系统的架构我们都应该保持简单易懂。大牛就是可以将复杂的东西“简单”的实现出来。注意“简单” 不等于 “简陋”。简单是代码足够精简，是经历了：先发散在聚敛，只保留了精华，去除糟粕后的结果。“简陋”： 是指代码毫无思想，毫无发散，也无聚敛，只能应对当前需求，可扩展性低。
YAGNI： You Ain’t Gonna Need It。 这条准则是 你不需要它 。是针对“大设计”（Big Design）提出来的，是“极限编程”提倡的原则，是指你自以为有用的功能，实际上都是用不到的。因此，除了核心的功能之外，其他的功能一概不要提前设计，这样可以大大加快开发进程。它背后的指导思想就是尽可能快、尽可能简单地让软件运行起来。
扩展原则：
在正式开发的时候，我们不可避免会出现一些代码冗余，为了扩展。比如我们在设计的时候会用模板模式来处理同一个业务模型业务。但是这里面可能就会存在代码冗余。因此，软件大师Martin Fowler在《重构》一书中提出的思想。
ROT:Rule of Three,也被称为 “三次原则” 。他是代码冗余和开发成本的平衡点。
三次原则指导我们可以通过以下步骤来写代码。
（ 1 ）第一次用到某个功能时，写一个特定的解决方法。
（ 2 ）第二次又用到的时候，复制上一次的代码。
（ 3 ）第三次出现的时候，才着手 “ 抽象化 ” ，写出通用的解决方 法。
POLA: Principle of least astonishment。短小惊奇原则：在《复杂》一书的第7章“度量复杂性”中，就阐述了用“惊奇度”来度量复杂度的方法，“惊奇度”越高，复杂性越大。所以不要让我们的代码出现太 “惊奇了”，不然大大降低代码的可读性。
设计模式：
SRP: 单一原则。要求每个软件模块职责要单一，衡量标准是模块是否只有一个 被修改的原因。职责越单一，被修改的原因就越少，模块的内聚性 （Cohesion）就越高，被复用的可能性就越大，也更容易被理解。 实现：匿名接口。 实现模型：贫血模型。
ISP: 接口隔离原则。客户端不应该依赖它不需要的接口。这个原则是基于 单一原则之上的原则。
OCP: 开闭原则。对修改关闭，对扩展开放。 实现： 多态。实现方式：继承，实现。有一个重要的实现设计原则： 依赖倒置原则。
DIP: 依赖导致原则。要求高层模块不应该依赖于低层模块，二者都应该依赖于抽象。抽象不应该依赖细节，细节应该依赖抽象。及利用接口，高层模块提供给底层模块的适配接口。这样让原来紧耦合的依赖 关系得以解耦，这样依赖方和被依赖方都有更高的灵活度。
里氏替换原则。程序中的父类型都应该可以正确地被子类型替换。但是 子类不能重写父类的方法，不然破坏了，父类可用性。肯能会导致错误使用父类的方法，导致了系统的不稳定性。为了保证不随意破坏LSP原则，我们可以将方法上使用 final 进行修饰。
