核心思想

1、找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
2、针对接口编程，而不是针对实现编程。
3、为了交互对象之间的松耦合设计而努力。

开闭原则

1、开闭原则是编程中最基础、最重要的设计原则；
2、一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。用抽象构建框架，用实现扩展细节；
3、当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

UML类图

示例代码

package principle;

/**
 * 开闭原则
 *
 * @author asyyr
 */
public class Ocp {
    public static void main(String[] args) {
        new GraphicEditor().draw(new Rectangle());
    }
}

// 作为使用者，新增Shape的类型，完全无需改动
class GraphicEditor {
    public void draw(Shape shape) {
        shape.draw();
    }
}

abstract class Shape {
    int m_type;

    abstract void draw();
}

class Rectangle extends Shape {

    private int m_type = 1;

    @Override
    void draw() {
        System.out.println("draw " + this.m_type + " shape");
    }
}

class Circle extends Shape {
    private int m_type = 2;

    @Override
    void draw() {
        System.out.println("draw " + this.m_type + " shape");
    }
}

里氏替换原则

继承可能的问题：

1、继承包含这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏；

2、继承在给程序设计带来便利的同时，也带来的弊端，比如使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其它的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到的子类的功能都有可能产生故障。

如何正确使用继承：里氏替换原则

如果对每个类型为T1的对象O1，都有类型为T2的对象O2，使得以T1定义的所有程序P在所有的对象O1都替换成O2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。换句话说，所有引用基类的地方必须能透明地使用其子类的对象。

里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合、组合、依赖来解决问题。或者在使用继承时，在子类中尽量不要重写父类的方法。

UML类图

示例代码

package principle;

/**
 * 里氏替换
 *
 * @author asyyr
 */
public class Liskow {
    public static void main(String[] args) {
        int num1 = 11;
        int num2 = 8;
        System.out.println(new AA().func1(num1, num2));
        System.out.println(new BB().func1(num1, num2));

        CC cc = new CC();
        cc.setaa(new AA());
        System.out.println(cc.func1(num1, num2));
    }
}

class AA {
    public int func1(int num1, int num2) {
        return num1 - num2;
    }
}

class BB extends AA {
    @Override
    public int func1(int num1, int num2) {
        return num1 + num2;
    }

    public int func2(int num1, int num2) {
        return num1 * num2;
    }
}

// 扩展 BB，使用组合关系依赖AA
class CC {
    private AA aa;

    public void setaa(AA aa) {
        this.aa = aa;
    }

    public int func1(int num1, int num2) {
        return this.aa.func1(num1, num2);
    }

    public int func2(int num1, int num2) {
        return num1 * num2;
    }
}

依赖倒转原则

1、高层模块不应该依赖底层模块，二者都应该依赖其抽象；
2、抽象不应该依赖细节，细节应该依赖抽象；
3、依赖倒转（倒置）的中心思想是面向接口编程；
4、依赖倒转原则是基于这样的设计理念：相对于细节的多变性，抽象的东西要稳定得多，以抽象为基础搭建的架构比以细节为基础的架构要稳定得多。在Java中，抽象指的是接口或者抽象类，细节指的是具体的实现类；
5、使用接口或者抽象类的目的是指定好规范，而不涉及任何具体的操作，把展示细节的任务交给它们的实现类来完成。

依赖关系通过接口、构造方法、setter方法传递。

注意事项：

1、低层模块尽量都要有抽象类或者接口，或者两者都有，程序稳定性更好；

2、变量的声明类型尽量是抽象类或者接口，这样的变量引用和实际对象间，就存在一个缓冲层，利于程序扩展和优化；

3、继承时需要遵循里氏替换原则。

UML类图

示例代码

package principle;

/**
 * 依赖倒转
 *
 * @author asyyr
 */
public class DependecyInversion {
    public static void main(String[] args) {
        // 1、接口传递
        /*Person person = new Person();
        person.receive(new Email());
        person.receive(new WeiXin());*/
        // 2、构造方法传递
        /*Person person = new Person(new Email());
        person.receive();
        person = new Person(new WeiXin());
        person.receive();*/
        // 3、setter方法传递，注意setter赋值步骤容易漏掉而导致空指针异常
        Person person = new Person();
        person.setReceiver(new Email());
        person.receive();
        person.setReceiver(new WeiXin());
        person.receive();
    }
}
// 1、接口传递 start
/*class Person {
    public void receive(IReceiver receiver) {
        System.out.println(receiver.getInfo());
    }
}

interface IReceiver {
    String getInfo();
}

class Email implements IReceiver {
    public String getInfo() {
        return "Email : Hello World";
    }
}

class WeiXin implements IReceiver {
    public String getInfo() {
        return "WeiXin : Hello World";
    }
}*/
// 1、接口传递 end

// 2、构造方法传递 start
/*class Person {
    private IReceiver receiver;

    public Person() {
    }

    public Person(IReceiver receiver) {
        this.receiver = receiver;
    }

    public void receive() {
        System.out.println(this.receiver.getInfo());
    }
}

interface IReceiver {
    String getInfo();
}

class Email implements IReceiver {
    public String getInfo() {
        return "Email : Hello World";
    }
}

class WeiXin implements IReceiver {
    public String getInfo() {
        return "WeiXin : Hello World";
    }
}*/
// 2、构造方法传递 end

// 3、setter方法传递 start
class Person {
    private IReceiver receiver;

    public Person() {
    }

    public void setReceiver(IReceiver receiver) {
        this.receiver = receiver;
    }

    public void receive() {
        System.out.println(this.receiver.getInfo());
    }
}

interface IReceiver {
    String getInfo();
}

class Email implements IReceiver {
    public String getInfo() {
        return "Email : Hello World";
    }
}

class WeiXin implements IReceiver {
    public String getInfo() {
        return "WeiXin : Hello World";
    }
}
// 3、setter方法传递 end

单一职责原则

对类来说，即一个类应该只负责一项职责，如类A负责两个不同的职责：职责1、职责2。当职责1需求变更而改变类A时，可能造成职责2执行错误，所以需要将类A的粒度分解为A1、A2。

优势：

1、降低类的复杂度，一个类只负责一项职责。

2、提高类的可读性、可维护性。

3、降低变更引起的风险。

注意事项：

单一职责同样也适用于方法。一个方法应该尽可能做好一件事情。如果一个方法处理的事情太多，其颗粒度会变得很粗，不利于重用。

UML类图

扩展阅读

blog.csdn.net/shulianghan…

接口隔离原则

客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上。

UML类图

示例代码

package principle;

/**
 * 接口隔离
 *
 * @author asyyr
 */
public class Segregation {
    public static void main(String[] args) {
        C c = new C();
        c.depend1(new A());
        c.depend2(new A());

        D d = new D();
        d.depend1(new B());
        d.depend4(new B());
    }
}

interface Interface1 {
    void operation1();
}

interface Interface2 {
    void operation2();
    void operation3();
}

interface Interface3 {
    void operation4();
    void operation5();
}

class A implements Interface1, Interface2 {
    @Override
    public void operation1() {
        System.out.println("A operation1");
    }

    @Override
    public void operation2() {
        System.out.println("A operation2");
    }

    @Override
    public void operation3() {
        System.out.println("A operation3");
    }
}

class B implements Interface1, Interface3 {
    @Override
    public void operation1() {
        System.out.println("B operation1");
    }

    @Override
    public void operation4() {
        System.out.println("B operation4");
    }

    @Override
    public void operation5() {
        System.out.println("B operation5");
    }
}

class C {
    public void depend1(Interface1 i) {
        i.operation1();
    }

    public void depend2(Interface2 i) {
        i.operation2();
    }

    public void depend3(Interface2 i) {
        i.operation3();
    }
}

class D {
    public void depend1(Interface1 i) {
        i.operation1();
    }

    public void depend4(Interface3 i) {
        i.operation4();
    }

    public void depend5(Interface3 i) {
        i.operation5();
    }
}

迪米特法则

1、一个对象应该对其它对象保持最少的了解；
2、类与类关系越密切，耦合度越大；
3、迪米特法则又叫最小知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供public方法，不外对泄漏任何信息；

迪米特法则还有个更简单的定义：只与直接的朋友通信。

直接的朋友：每个对象都会与其它对象有耦合关系，只要两个对象之间有耦合关系，就可以说这两个对象之间是朋友关系。耦合的方式很多，依赖、关联、组合、聚合等，其中称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。

注意事项：

1、迪米特法则的核心是降低类之间的耦合度；

2、由于每个类都不可避免存在依赖，因此迪米特法则只是要求降低类间（对象间）耦合关系，并不是要求完全没有依赖关系。

UML类图

示例代码

public class Dimitri {
    public static void main(String[] args) {
        Star star = new Star("Star");
        Fan fan = new Fan("Fan");
        Company company = new Company("Company");

        Agent agent = new Agent();
        agent.setStar(star);
        agent.setFan(fan);
        agent.setCompany(company);

        agent.meeting();
        agent.business();
    }
}

class Star {
    private String name;

    public Star(String name) {
        this.name = name;
    }

    public String getName() {
        return this.name;
    }
}

class Fan {
    private String name;

    public Fan(String name) {
        this.name = name;
    }

    public String getName() {
        return this.name;
    }
}

class Company {
    private String name;

    public Company(String name) {
        this.name = name;
    }

    public String getName() {
        return this.name;
    }
}

class Agent {
    private Star star;
    private Fan fan;
    private Company company;

    public void setStar(Star star) {
        this.star = star;
    }

    public void setFan(Fan fan) {
        this.fan = fan;
    }

    public void setCompany(Company company) {
        this.company = company;
    }

    public void meeting() {
        System.out.println(fan.getName() + "与明星" + star.getName() + "又见面了");
    }

    public void business() {
        System.out.println(company.getName() + "与明星" + star.getName() + "洽谈业务");
    }
}

合成复用原则

尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。

通常类的复用分为继承复用和合成复用两种。

继承复用虽然有简单和易实现的优点，但它也存在以下缺点：

1、继承复用破坏了类的封装性。因为继承会将父类的实现细节暴露给子类，父类对子类是透明的，所以这种复用又称为“白箱”复用。

2、子类与父类的耦合度高。父类的实现的任何改变都会导致子类的实现发生变化，这不利于类的扩展与维护。

3、它限制了复用的灵活性。从父类继承而来的实现是静态的，在编译时已经定义，所以在运行时不可能发生变化。

采用组合或聚合复用时，可以将已有对象纳入新对象中，使之成为新对象的一部分，新对象可以调用已有对象的功能，它有以下优点：

1、它维持了类的封装性。因为成分对象的内部细节是新对象看不见的，所以这种复用又称为“黑箱”复用。

2、对象间的耦合度低。可以在类的成员位置声明抽象。

3、复用的灵活性高。这种复用可以在运行时动态进行，新对象可以动态地引用与成分对象类型相同的对象。

UML类图

继承复用类图

组合复用类图

示例代码

public class Multiplex {
    public static void main(String[] args) {
        Color color = new Red("red");
        Energy energy = new Electric("electric");

        Car car = new Car();
        car.setColor(color);
        car.setEnergy(energy);
        car.move();
    }
}

class Car {
    private Color color;
    private Energy energy;

    public void setColor(Color color) {
        this.color = color;
    }

    public void setEnergy(Energy energy) {
        this.energy = energy;
    }

    public void move() {
        System.out.println("A " + this.color.getColor() + " car is running by " + this.energy.getEnergy());
    }
}

interface Color {
    String getColor();
}

class Red implements Color {
    private String name;

    public Red(String name) {
        this.name = name;
    }

    @Override
    public String getColor() {
        return this.name;
    }
}

class White implements Color {

    private String name;

    public White(String name) {
        this.name = name;
    }

    @Override
    public String getColor() {
        return this.name;
    }
}

interface Energy {
    String getEnergy();
}

class Petrol implements Energy {
    private String name;

    public Petrol(String name) {
        this.name = name;
    }

    @Override
    public String getEnergy() {
        return this.name;
    }
}

class Electric implements Energy {
    private String name;

    public Electric(String name) {
        this.name = name;
    }

    @Override
    public String getEnergy() {
        return this.name;
    }
}