设计模式六大原则

一款优秀软件离不开一个优秀的架构，一个优秀的架构也离不开设计模式，在学习设计模式之前，我们需要学习并掌握代码设计的基本原则，打好基础从设计模式的六大原则开始，六大原则如下：

  • 单一职责原则
  • 里氏替换原则
  • 依赖倒置原则
  • 接口隔离原则
  • 迪米特原则
  • 开闭原则

下面是对六大原则的具体介绍：

单一职责原则

单一职责原则的英文名称是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<Room> mRooms = new ArrayList<>();

    public Mediator() {
        for (int i = 0; i < 5; i++) {
            mRooms.add(new Room(10 + i, (10 + i) * 150));
        }
    }

    public List<Room> 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<Room> 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<Room> 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了，可以直接修改这一个类就可以。

©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 216,496评论 6赞 501
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 92,407评论 3赞 392
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 162,632评论 0赞 353
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 58,180评论 1赞 292
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 67,198评论 6赞 388
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 51,165评论 1赞 299
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 40,052评论 3赞 418
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 38,910评论 0赞 274
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 45,324评论 1赞 310
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,542评论 2赞 332
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,711评论 1赞 348
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 35,424评论 5赞 343
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 41,017评论 3赞 326
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,668评论 0赞 22
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,823评论 1赞 269
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 47,722评论 2赞 368
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 44,611评论 2赞 353

推荐阅读更多精彩内容

  • 设计模式六大原则
    设计模式之六大原则（转载） 关于设计模式的六大设计原则的资料网上很多...
    霄霄霄霄阅读 899评论 0赞 1
  • 设计模式六大原则（面向对象语言）
    前言 设计模式六大原则网上资料比较多比较乱，本文将网上的一些好的资料做一下整理，以便随时翻阅。友情提示，设计模式虽...
    简单的土豆阅读 1,433评论 0赞 10
  • 设计模式六大原则
    什么是设计模式？设计模式（Design Pattern）是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的...
    星星_点灯阅读 399评论 0赞 0
  • 设计模式六大原则
    设计模式六大原则 设计模式六大原则（1）：单一职责原则 定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类...
    viva158阅读 765评论 0赞 1
  • 大爱禹城
    本文参加#感悟三下乡，青春筑梦行#活动，本人承诺，文章内容为原创，且未在其他平台发表过。 7月10日，我来到了德州...
    wuli恬恬阅读 396评论 8赞 14