一款优秀软件离不开一个优秀的架构，一个优秀的架构也离不开设计模式，在学习设计模式之前，我们需要学习并掌握代码设计的基本原则，打好基础从设计模式的六大原则开始，六大原则如下：
- 单一职责原则
- 里氏替换原则
- 依赖倒置原则
- 接口隔离原则
- 迪米特原则
- 开闭原则
下面是对六大原则的具体介绍：
单一职责原则
单一职责原则的英文名称是Single Responsibility Principe，缩写是SRP。定义：就一个类而言，不要存在多于一个导致类变更的原因。通俗地讲，就是一个类中应该是一组与其职责相关性很高的方法和数据的封装，而不去承担多余的职责。
例如一个用户系统，有姓名和年龄两个属性：
public class Person {
private String name;
private String age;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getAge() {
return age;
}
public void setAge(String age) {
this.age = age;
}
public void changeAge(String age) {
//...
}
public void changeName(String age) {
//...
}
}
在这个类中，name和age的set，get方法是是属于数据类型也就是业务对象的相关方法，但是changeAge和changeName需要跟服务器进行交互，是属于业务逻辑相关方法，根据单一职责原则，我们需要将业务和数据分开：
public class Person {
private String name;
private String age;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getAge() {
return age;
}
public void setAge(String age) {
this.age = age;
}
}
public class PersonLogic {
public void changeAge(String age) {
//...
}
public void changeName(String age) {
//...
}
}
优点：可以降低类的复杂度，一个类只负责一项职责；提高类的可读性，提高系统的可维护性；当修改一个功能时，可以显著降低对其他功能的影响。
里氏替换原则
里氏替换原则的英文名称是Liskov Substitution Principle，缩写是LSP。定义：所有引用基类（父类）的地方必须能透明地使用其子类的对象。通俗地讲，所有使用父类的地方都可以替换为子类，不会产生任何错误和异常，但反过来替换就不行了，子类出现的地方未必能用父类替换。
根据定义我们可以这样理解：
- 子类必须完全实现父类的方法
- 子类可以有自己的个性
- 覆写或实现父类的方法时输入参数可以宽于或等于父类参数
- 覆写或实现父类的方法时输出结果可以窄于或等于父类参数
看下面参数替换的例子：
public class Father {
public void printf(ArrayList list) {
System.out.printf("父类方法");
}
public List printf() {
System.out.printf("父类方法");
return new ArrayList();
}
public void printf(HashMap map) {
System.out.printf("父类方法");
}
}
public class Son extends Father {
@Override
public void printf(ArrayList list) {
System.out.printf("子类方法--重写父类方法");
}
@Override
public ArrayList printf() {
System.out.printf("子类方法--重写父类方法");
// 在子类重写父类方法中，返回值必须窄于或等于父类返回值类型
return new ArrayList();
}
// 重载方法--输入参数应该宽于或等于父类参数，以免造成子类替换父类产生逻辑混乱
public void printf(Map map) {
System.out.printf("子类方法");
}
}
优点：提高代码的可扩展性。
依赖倒置原则
依赖倒置原则的英文名称是Dependence Inversion Principle，缩写是DIP。定义：模块间的依赖通过抽象来产生，实现类之间不直接产生依赖关系，他们的依赖关系是通过接口或抽象类产生的。通俗地讲，就是面向接口或抽象类编程。
例如，父亲给孩子讲故事，需要给他一本书，或一份报纸：
class Book{
public String get(){
return "书";
}
}
class NewsPaper{
public String get(){
return "报纸";
}
}
class Father{
public void read(Book book){
System.out.println("爸爸读"+book.get());
}
public void read(NewsPaper news){
System.out.println("爸爸读"+news.get());
}
}
public class Client {
public static void main(String[] args){
Father f = new Father();
f.read(new Book());
f.read(new NewsPaper());
}
}
如果再新增一个可读的东西，如Magazine(杂志)，那我们要重新写一个Magazine类，同时在Father类中还要新增一个read方法。所以我们可以这样优化一下：
interface IReader{
public String get();
}
然后让Book Newspaper Magazine类都实现这个接口，父类则可简化为：
class Father{
public void read(IReader reader){
System.out.println("爸爸读"+reader.get());
}
}
优点：提高代码的可变性，简化代码逻辑。
接口隔离原则
接口隔离原则的英文名称是Interface Segregation Principle，缩写是ISP。定义：一个类对另一个类的依赖应该建立在最小的接口上。通俗地讲，尽量建立单一细化的接口，接口中的方法尽量少，而不要建立庞大臃肿的接口，也就是说我们要为各个类建立专用的接口，而不要试图建立一个很庞大的接口供所有依赖它的类调用，采样接口隔离原则对接口进行约束，在一个类去实现接口的时候，不应该去实现他不需要的方法。
常用作法：
1.为依赖接口的类提供定制服务，只暴露给类它需要的方法，不需要的方法则隐藏起来。
2.提交内聚，减少对外交互，接口方法尽量少用public修饰，接口是对外的承诺，方法越少对变更产生的风险越小。
interface I {
public void method1();
public void method2();
public void method3();
public void method4();
public void method5();
}
class A{
public void depend1(I i){
i.method1();
}
public void depend2(I i){
i.method2();
}
public void depend3(I i){
i.method3();
}
}
class B implements I{
public void method1() {
System.out.println("类B实现接口I的方法1");
}
public void method2() {
System.out.println("类B实现接口I的方法2");
}
public void method3() {
System.out.println("类B实现接口I的方法3");
}
public void method4() {}
public void method5() {}
}
class C{
public void depend1(I i){
i.method1();
}
public void depend2(I i){
i.method4();
}
public void depend3(I i){
i.method5();
}
}
class D implements I{
public void method1() {
System.out.println("类D实现接口I的方法1");
}
//对于类D来说，method2和method3不是必需的，但是由于接口A中有这两个方法，
//所以在实现过程中即使这两个方法的方法体为空，也要将这两个没有作用的方法进行实现。
public void method2() {}
public void method3() {}
public void method4() {
System.out.println("类D实现接口I的方法4");
}
public void method5() {
System.out.println("类D实现接口I的方法5");
}
}
public class Client{
public static void main(String[] args){
A a = new A();
a.depend1(new B());
a.depend2(new B());
a.depend3(new B());
C c = new C();
c.depend1(new D());
c.depend2(new D());
c.depend3(new D());
}
}
可以看到，如果接口过于臃肿，只要接口中出现的方法，不管对依赖于它的类有没有用处，实现类中都必须去实现这些方法，这显然不是好的设计。如果将这个设计修改为符合接口隔离原则，就必须对接口I进行拆分。在这里我们将原有的接口I按合理的方式拆分为三个接口。
interface I1 {
public void method1();
}
interface I2 {
public void method2();
public void method3();
}
interface I3 {
public void method4();
public void method5();
}
class A{
public void depend1(I1 i){
i.method1();
}
public void depend2(I2 i){
i.method2();
}
public void depend3(I2 i){
i.method3();
}
}
class B implements I1, I2{
public void method1() {
System.out.println("类B实现接口I1的方法1");
}
public void method2() {
System.out.println("类B实现接口I2的方法2");
}
public void method3() {
System.out.println("类B实现接口I2的方法3");
}
}
class C{
public void depend1(I1 i){
i.method1();
}
public void depend2(I3 i){
i.method4();
}
public void depend3(I3 i){
i.method5();
}
}
class D implements I1, I3{
public void method1() {
System.out.println("类D实现接口I1的方法1");
}
public void method4() {
System.out.println("类D实现接口I3的方法4");
}
public void method5() {
System.out.println("类D实现接口I3的方法5");
}
}
优点：系统解耦和，有利于代码的重构、更改和重新部署。
迪米特原则
迪米特原则的英文全称是Law of Demeter，缩写是LOD，也称为最少知识原则（Least Knowledge Principle）。定义：一个软件实体应当尽可能少地与其他实体发生相互作用。通俗地讲，就是尽量减少对象之间的交互，如果两个对象之间不必直接通信，那么这两个对象就不应该发生任何直接的相互作用。
例如，一个人要租房，要求了房间的面积和租金，中介将符合我们要求的房间提供给我们就可以：
/**
* 房间
*/
public class Room {
public float area;
public float price;
public Room(float area, float price){
this.area = area;
this.price = price;
}
@Override
public String toString() {
return "Room{" + "area=" + area + ", price=" + price + '}';
}
}
/**
* 中介
*/
public class Mediator {
private List mRooms = new ArrayList<>();
public Mediator() {
for (int i = 0; i < 5; i++) {
mRooms.add(new Room(10 + i, (10 + i) * 150));
}
}
public List getAllRooms() {
return mRooms;
}
}
/**
* 租户
*/
public class Tenant {
public float minArea = 20f;
public float maxArea = 100f;
public float minPrice = 100f;
public float maxPrice = 1000f;
public void rentRoom(Mediator mediator) {
List rooms = mediator.getAllRooms();
for (Room room : rooms) {
if (isSuitable(room)) {
System.out.print("租到房子啦：" + room);
break;
}
}
}
private boolean isSuitable(Room room) {
return room.price > minPrice && room.price < maxPrice && room.area > minArea && room.area < minArea;
}
}
从上面可以看出，Tenant不仅依赖了Mediator类，还频繁地与Room类打交道，当Room变化时Tenant也必须跟着变化，而我们只是要通过中介租房罢了，所以我们真正的“朋友”就只有Mediator，修改后如下：
/**
* 中介
*/
public class Mediator {
private List mRooms = new ArrayList<>();
public Mediator() {
for (int i = 0; i < 5; i++) {
mRooms.add(new Room(14 + i, (14 + i) * 150));
}
}
public Room rentOut(float minArea, float maxArea, float minPrice, float maxPrice) {
for (Room room : mRooms) {
if (isSuitable(room, minArea, maxArea, minPrice, maxPrice)) {
return room;
}
}
return null;
}
private boolean isSuitable(Room room, float minArea, float maxArea, float minPrice, float maxPrice) {
return room.price > minPrice && room.price < maxPrice && room.area > minArea && room.area < minArea;
}
}
/**
* 租户
*/
public class Tenant {
public float minArea = 20f;
public float maxArea = 100f;
public float minPrice = 500f;
public float maxPrice = 1000f;
public void rentRoom(Mediator mediator){
System.out.print("租到房子啦："+mediator.rentOut(minArea, maxArea, minPrice, maxPrice));
}
}
优点：降低耦合，提高可扩展性。
开闭原则
开闭原则的英文名称是Open Close Principle，缩写是OCP。定义：软件中的对象（类、模块、函数等）对于扩展是允许的，但是对于修改是不允许的。通俗地讲，如果有新的需求，不能去修改实现类的具体实现，而应该是新增创建一个实现了其公共接口的子类，在新的子类中做新需求的实现。
例如如下常见例子：
public interface ICar {
public String getName();
public float getPrice();
}
public class Car implements ICar{
private String name;
private float price;
public Car(String name,float price){
this.name = name;
this.price = price;
}
@Override
public String getName() {
return name;
}
@Override
public float getPrice() {
return price;
}
}
当有一天我们获取车的价格需要打折时，可以重新写一个类SaleCar：
public class SaleCar extends Car{
public SaleCar(String name, float price) {
super(name, price);
}
@Override
public float getPrice() {
return super.getPrice()*8/10;
}
}
优点：让程序更稳定，更灵活，当有新功能出现的时候，可以在不修改原有的逻辑的基础上，实现一个新的类，这样原有的逻辑没有变，新的需求也实现了。当有一天出现bug了，可以直接修改这一个类就可以。