设计原则之旅（一）：单一职责

设计模式 前端之家
前端之家收集整理的这篇文章主要介绍了设计原则之旅（一）：单一职责，前端之家小编觉得挺不错的，现在分享给大家，也给大家做个参考。

简称：

单一职责原则的英文名称是Single Responsibility Principle， 简称RSP。

定义：

RSP 的原话解释是：There should never be more than one reason for a class to change. ( 不要存在多于一个导致类变更的原因 ) 。通俗的说，即一个类只负责一项职责，而不应该同时负责多个职责。

问题由来：

类 T 负责两个不同的职责：职责 P1，职责 P2。当由于职责 P1 需求发生改变而需要修改类 T 时，有可能会导致原本运行正常的职责 P2 功能发生故障。

解决方案：

遵循单一职责原则。分别建立两个类 T1、T2，使 T1 完成职责 P1 功能，T2 完成职责 P2 功能。这样，当修改类 T1 时，不会使职责 P2 发生故障风险；同理，当修改 T2 时，也不会使职责 P1 发生故障风险。

举例说明

需求：实现一个购物车功能，购物车主要用于存放图书，根据书的价格，计算所有图书的总价格。

示例代码：

图书类：

//商品类
public class Book {

    private String name;    //商品名称

    private double price;   //商品价格

    public Book(String name,double price) {
        super();
        this.name = name;
        this.price = price;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public double getPrice() {
        return price;
    }

    public void setPrice(double price) {
        this.price = price;
    }
}

购物车类：

//购物车
public class ShoppingCart {

    //存放添加的图书
    private List<Book> list = new ArrayList<Book>();

    //添加图书
    public void addBook(Book book){
        list.add(book);
    };

    //删除图书
    public void removeBook(Book book){
        list.remove(book);
    };

    //结账
    public int checkOut(){
        double total = 0;
        for(Book book : list){
            total = total+book.getPrice();
        }
        return total;
    }
}

客户端代码：

//客户端代码
public class Client {

    public static void main(String[] args) {

        Book book1 = new Book("红楼梦",50);
        Book book2 = new Book("三国演义",40);
        Book book3 = new Book("西游记",30);
        Book book4 = new Book("水浒传",20);

        ShoppingCart shoppingCart = new ShoppingCart();
        shoppingCart.addBook(book1);
        shoppingCart.addBook(book2);
        shoppingCart.addBook(book3);
        shoppingCart.addBook(book4);

        double total = shoppingCart.checkOut();
        System.out.println("所有图书价格为："+total);
    }
}

输出结果：

OK，以上代码“ 完美 ”解决客户需求。

当然，所谓的 完美 ”是建立在需求不变的情况下。很遗憾，客户的需求总是在不断变化的，程序上线以后，客户发现没有打折功能，现在，客户要求对所有的“ 红楼梦 ”图书打 8 折促销，那我们的程序改如何修改呢？

有些小伙伴应该可能会这么修改：修改 ShoppingCart 类中的 checkOut 方法，快速实现客户需求.

//购物车
public class ShoppingCart {

    //存放添加的图书
    private List<Book> list = new ArrayList<Book>();

    //添加图书
    public void addBook(Book book){
        list.add(book);
    };

    //删除图书
    public void removeBook(Book book){
        list.remove(book);
    };

    //结账
    public double checkOut(){
        double total = 0;
        for(Book book : list){  
            if("红楼梦".equals(book.getName())){
                total = total+book.getPrice()*0.8;
            }else{
                total = total+book.getPrice();
            }
        }
        return total;
    }
}

输出结果满足客户需求

过来几天，客户需求又有了新的变化，对所有的“ 红楼梦 ”图书打 8 折促销，所有的“ 西游记 ”打 6 折。按照之前的修改逻辑，如下：

//购物车
public class ShoppingCart {

    //存放添加的图书
    private List<Book> list = new ArrayList<Book>();

    //添加图书
    public void addBook(Book book){
        list.add(book);
    };

    //删除图书
    public void removeBook(Book book){
        list.remove(book);
    };

    //结账
    public double checkOut(){
        double total = 0;
        for(Book book : list){
            if("红楼梦".equals(book.getName())){
                total = total+book.getPrice()*0.8;
            }if("西游记".equals(book.getName())){
                total = total+book.getPrice()*0.6;
            }else{
                total = total+book.getPrice();
            }
        }
        return total;
    }
}

同样快速满足客户需求

示例代码分析

上边的代码，初看起来很像也没太多问题，而且还能够快速满足客户端需求，对某些项目来说，快速满足客户需求是第一要素，但是，这样写存在什么隐患呢？

客户的需求总是的在不停的变化的，按照上边的设计，客户的每一次需求变动，我们多需要修改我们的 ShoppingCart 类，客户的需求变化频率越高，需求越复杂，ShoppingCart 类也改动也频繁， 复杂度也是成倍增加，而且代码的复用性很差，如果客户需要改回原来的选取，我们同样还是需要修改我们的ShoppingCart 类， 改来改去之后，我们会发现我们之前设计的 ShoppingCart 类的 checkOut 方法已经变的非常臃肿了，以至于没法维护了。

隐患分析：

上述代码之所以会存在那么多的隐患，根本的原因在于 ShoppingCart 的设计违背的“单一职责原则”与“ 开闭原则 ”（后期会讲解），checkOut 方法即承担了统计总价职责，又承担了打折优惠职责，以至于优惠职责需求变动的时候，代码统计总价的逻辑也受到相应的影响。

解决方案：

遵循单一职责原则，拆分 ShoppingCart 职责，ShoppingCart 的职责是收集图书，输出所有图书的结账时的总价格，至于打折优惠职责交给专门的类去处理。考虑的到打折优惠是一个变化的需求，所有，我们应该将这种行为提取处来，做为一个抽象接口，具体实现交给实现类去处理。

示例代码：

提取打折策略抽象接口：

//打折策略
public interface DiscountStrategy {

    //打折抽象方法
    public double discount(List<Book> list);
}

实现默认打折策略：

//默认打折策略：不打折
public class DefalutDiscountStrategy implements DiscountStrategy{

    @Override
    public double discount(List<Book> list) {
        double total = 0;
        for(Book book : list){
            total = total+book.getPrice();
        }
        return total;
    }
}

购物车与打折实体通过打折策略抽象接口建立关系：

//购物车
public class ShoppingCart {

    //存放添加的图书
    private List<Book> list = new ArrayList<Book>();

    private DiscountStrategy discountStrategy;

    //添加图书
    public void addBook(Book book){
        list.add(book);
    };

    //删除图书
    public void removeBook(Book book){
        list.remove(book);
    };

    //设置打折策略
    public void setDiscountStrategy(DiscountStrategy discountStrategy) {
        this.discountStrategy = discountStrategy;
    }

    //结账
    public double checkOut(){

        if(discountStrategy== null){
            //客户没有设置打折策略，使用默认打折策略
            discountStrategy = new DefalutDiscountStrategy();
        }

        double total = discountStrategy.discount(list);

        return total;
    }
}

客户端，根据业务需求，自定义打折优惠策略

//红楼梦打 8 折策略
public class FirstDiscountStrategy implements DiscountStrategy{

    @Override
    public double discount(List<Book> list) {
        double total = 0;
        for(Book book : list){
            if("红楼梦".equals(book.getName())){
                total = total+book.getPrice()*0.8;
            }else{
                total = total+book.getPrice();
            }
        }
        return total;
    }
}

客户端代码：

//客户端代码
public class Client {

    public static void main(String[] args) {

        Book book1 = new Book("红楼梦",20);

        ShoppingCart shoppingCart = new ShoppingCart();

        shoppingCart.addBook(book1);
        shoppingCart.addBook(book2);
        shoppingCart.addBook(book3);
        shoppingCart.addBook(book4);

        //客户设置打折策略
        DiscountStrategy discountStrategy = new FirstDiscountStrategy();
        shoppingCart.setDiscountStrategy(discountStrategy);

        double total = shoppingCart.checkOut();
        System.out.println("所有图书价格为："+total);
    }
}

后期，客户业务需求如果变化，只需要实现 DiscountStrategy 接口，自己定义属于自己的策略，而我们的 ShoppingCart 类则无需做任何修改，ShoppingCart 的职责也非常清晰。

总结分析：

遵循单一职责原则优点：

  • 减低类的复杂度，一个类只负责一项职责了，其业务逻辑自然就变简单了。
  • 提示类的可读性，提升系统的维护性。
  • 减低需求变化代理的风险，如果遵循了单一职责，类之间的耦合性也就减低了，内聚性增强了，需求变换带来的风险自然就降低了。

欢迎关注本人公众号：“Android 之旅”，查看更多相关博客

猜你在找的设计模式相关文章

适配器模式-让不兼容的接口得以适配
适配器模式将一个类的接口转换成客户期望的另一个接口，使得原本接口不兼容的类可以相互合...
策略模式-定义一个算法族
策略模式定义了一系列算法族，并封装在类中，它们之间可以互相替换，此模式让算法的变化独...
设计模式之高质量代码
设计模式讲的是如何编写可扩展、可维护、可读的高质量代码，它是针对软件开发中经常遇到的...
模板方法模式-封装一套算法流程
模板方法模式在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中，使得子类可以在...
迭代器模式-统一集合的遍历方式
迭代器模式提供了一种方法，用于遍历集合对象中的元素，而又不暴露其内部的细节。
单例模式的五种实现方式及优缺点
单例模式（Singleton Design Pattern）保证一个类只能有一个实例，并提供一个全局访问点。
组合模式-统一的处理个别对象与组合对象
组合模式可以将对象组合成树形结构来表示“整体-部分”的层次结构，使得客户可以用一致的方...
装饰者模式-动态的包装原有对象的行为
装饰者模式能够更灵活的，动态的给对象添加其它功能，而不需要修改任何现有的底层代码。
观察者模式-将消息通知给观察者
观察者模式（Observer Design Pattern）定义了对象之间的一对多依赖，当对象状态改变的时候...
代理模式-访问对象的代理而非其本身
代理模式为对象提供一个代理，来控制对该对象的访问。代理模式在不改变原始类代码的情况下...
算法设计模式多媒体技术正则表达式ElasticsearchFlinkHadoopIDE
受约束摘*day25Java常用类库置信lamda留存持续录入年后正则表达式303.17regularexpre匹多模适20130322基础理论pathmunge涵义reectok需要转义的特资源分享validationex简明魔法里弄形如源码实现完备actionscript