java设计模式--六大原则

一、单一职责原则

　　单一职责原则：就一个类而言，应该仅有一个引起它变化的原因。通俗来说，就是互相不相关的属性和方法不要放在一个类中，就好比之前简单工厂模式中介绍的那样，客户端（customer）应该与工厂(factory)建立成两个类，当客户想要工厂中的另一种产品时，只需要修改客户端，再或者，工厂想要生产新产品，就只需在工厂类中添加，客户端的类而不需修改。这种只有一个动机的去改变一个类就是单一职责原则。

 

//产品接口
public interface product {

    void run();

}

public class car implements product {
    @override
    public void run() {
        system.out.println("drive car");
    }
}

public class bicycle implements product {
    @override
    public void run() {
        system.out.println("ride on a bicycle");
    }
}

//工厂类
public class factory {
    public static product createproduct(string productname){
        product product = null;
        switch (productname){
            case "car":
                product = new car();
                break;
            case "bicycle" :
                product = new bicycle();
                break;
        }
        return product;
    }
}

//客户端
public class customer {
    public static void main(string[] args) {
        product car = factory.createproduct("car");
        car.run();
        product bicycle = factory.createproduct("bicycle");
        bicycle.run();
    }
}

 

二、里氏替换原则

　　里氏替换原则：子类型必须能够替换掉它们的父类型。其实就是在一个程序里，某一个地方使用的是一个父类，那么把父类换成它的子类同样适用。另外子类一般不该重写父类的方法，因为父类的方法一般都是对外公布的接口，是具有不可变性的，你不该将一些不该变化的东西给修改掉。因为一般我们认为，父类可以完成的事情，子类也可以，如果重写父类的方法并且因此出错，将来如果用子类替换父类就会出现问题。

 

三、依赖倒转原则

　　1.高层模块不应该依赖低层模块，两个都应该依赖抽象

　　2.抽象不应该依赖细节，细节应该依赖抽象

　　通俗来说就是依赖接口编程，就比如上面的简单工厂的例子，我们修改一下使其更直观一些，如果没有product这个接口（如下所示），我们就必须去调用car.run(),此时必须传入一个car对象，那么如果以后我们不想用car想用bicycle或者其他交通工具呢，那就得新增多个drive类，所以最好的方法是建立一个product接口，让所有产品都去实现这个接口，这样，客户端也不必去关心从哪个drive类中获取所需要的run()方法，直接将想用的交通工具传进工厂类factory中就可以了。

public class car {
    public void run() {
        system.out.println("drive car");
    }
}

public class drive{
    public static void gohome(car car){

        car.run();
    }
}

public class customer {
    public static void main(string[] args) {
        car car = new car();
        drive.gohome(car);

    }
}

 

四、接口隔离原则

　　接口隔离原则：一个接口的行为应该尽可能的小，其实就是接口里的方法一定要是所有实现这个接口的类所能实现的。比如我们定义了一个car接口，里面有两个方法，驾驶和导航，但是实际情况是并不是所有的汽车都有导航的功能，这样的话没有导航功能的汽车实现这个接口的时候就只能把导航的这个方法空着，所以我们最好把navigation()这个方法从接口中去掉。

public interface car {
    
    //行驶
    void run();
    //导航
    void navigation();
    
}

 

五、迪米特法则

　　迪米特法则：如果两个类不比彼此直接通信，那么他们就不应该直接发生作用，它强调的是松耦合，这样的话一个类修改也不会对其他类有太大的影响。

　　看如下实例有三个类，car（汽车），driver（司机），customer（顾客）和一个测试类，可以看到customer类中new了一个car，这就违反了迪米特法则，因为驾驶汽车的活应该交由司机处理，car类应该是司机内部的类

public class car {
    public void run(){
        system.out.println("汽车启动...");
    }
}

public class driver {
    public void drivecar(car car){
        system.out.println("司机已就绪...");
        car.run();
    }
}

public class customer {
    public void gohome(driver driver){
        car car = new car();
        driver.drivecar(car);
    }
}

public class test {
    public static void main(string[] args) {
        customer customer = new customer();
        customer.gohome(new driver());
    }
}

修改后的类为

public class customer {
    public void gohome(driver driver){
        driver.drivecar();
    }
}

public class driver {

    car car = null;
    public driver(car car){
        this.car = car;
    }
    public void drivecar(){
        system.out.println("司机已就绪...");
        car.run();
    }
}

public class test {
    public static void main(string[] args) {
        customer customer = new customer();
        car car = new car();
        customer.gohome(new driver(car));
    }
}

这样的话，customer就不会知道car实现的细节，全权交由driver处理。

 

六、开放-封闭原则

 开放-封闭原则：就是类，函数等应该是可以扩展，但是不能修改。这个原则有两个特征，对于扩展是开放的，对于更改是关闭的。但是事实情况是模块不可能完全封闭的，总会有一些变化，但是这时就需要我们去预测可能发生的变化，然后构造抽象来隔离哪些变化，这样的话以后更改起来就可以保持相对稳定，使一个地方的变化对其他地方的影响尽可能的小。