七大原则
单一职责原则
一个类应当只负责一项职责，在业务逻辑简单的情况下 也可以一个方法负责一项职责
优点
降低类的复杂度；
提高类的可读性，可维护性；
降低变更类引起的风险
注意事项
在业务逻辑非常简单的情况下，类会增多；所以可以在代码级违反单一职责原则。
只有类中方法数量足够少，可以在方法级别保持单一职责原则
接口隔离原则(Interface Segregation Principle)
具体类不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上
例如A类实现接口I，B类实现接口I，C类实现接口I；如图
B类只需要m1 m2 m3方法，C类只需要 m4 m5方法，但被迫把接口的所有方法都实现了。
对 I 接口进行拆分成多个小接口
I1 接口声明 m1 m2 m3方法，I2 接口声明 m3 m4方法
A类实现 I1 接口 I2 接口；B类实现 I1 接口；C类实现 I2接口;
这样就避免子类强迫实现不需要的接口方法，减少方法的声明，提高类的可读性，可维护性；
充分利用的Java的多实现
依赖倒转(倒置)原则(Interface Segregation Principle)
高层模块不应该依赖低层模块，二者都应该依赖其抽象；
抽象不应该依赖细节，细节应该依赖抽象；
依赖倒转(倒置)的中心思想是面向接口编程；
相对于细节的多变性，抽象的东西要稳定的多；
以抽象为基础搭建的架构比以细节为基础的架构要稳定的多；
在java中，抽象指的是接口或抽象类，细节就是具体的实现类；
使用：
注意事项：
低层模块尽量都要有抽象类或接口，或者两者都有，程序稳定性更好.
变量的声明类型尽量是抽象类或接口, 这样我们的变量引用和实际对象间，就存在一个缓冲层，利于程序扩展和优化
继承时遵循里氏替换原则
里氏替换原则(Liskov Substitution Principle)
任何基类可以出现的方法，在子类也应该可以出现
在继承父类时，对于父类中已经定义好的结构方法，不应该对其进行重写；
如上图所示；父类(Base)中有add()方法；且已经实现好的业务逻辑；但子类(Sub)对其重写了；
使得父类的原有业务逻辑发生了改变;
注意事项：
继承再给程序带来便利的同时，也带来了弊端；继承会对程序有侵入性，
比如一个类被其他类所继承，当这个类的所需要修改时，必选要考虑到所有子类，
会不会因为父类的修改而可能产生故障；
再继承父类，不要对父类定义好的算法骨架进行重写；
开闭原则(Open Closed Principle)
对扩展开放，对修改关闭；在程序需要进行扩展的时候，不去修改原有的代码，而是扩展原有的代码；
编程中遵循其它原则，以及使用设计模式的目的就是遵循开闭原则。
如下图所示；现在需要做一个绘制图形的功能，有矩形，圆形；
由此可以定义好一个基类，声明抽象方法由子类实现；
下面需要再增加一个绘制三角形的类；由此只需要再定义一个三角形的类(Triangle)去继承绘制图形的基类(Drawing)，然后实现抽象方法即可;
完全不需要去改动原有的代码，即可扩展一个功能；
注意事项：
在使用的时候，应当用基类(Drawing)作为变量类型；满足依赖倒转(倒置)原则(面向接口或抽象类编程)
迪米特法则(Demeter Principle)最少知道原则
一个对象应该对其他对象保持最少的了解；
类与类关系越密切，耦合度越大；
即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的public 方法，不对外泄露任何信息
即A类引用B类，B类中的定义好的业务逻辑方法，只对本类使用的，不应该使用 piblic修饰符，而本类中的 public修饰的方法，再去调用本类中其他修饰符的方法。
合成复用原则
原则是尽量使用合成/聚合的方式，而不是使用继承；
如果仅仅只是使用某个类的一些方法，不应该去继承这个类
如下一个类，其他类只是想用其中的某些方法；如果继承，显然耦合度很大；
可以使用 合成/聚合的方式 列如：
以上只是简单的代码演示，实际情况因根据项目而定。
设计原则核心思想
- 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代
码混在一起。 - 针对接口编程，而不是针对实现编程。
- 为了交互对象之间的松耦合设计