单一职责原则

最新推荐文章于 2024-09-15 22:03:14 发布
置顶 最新推荐文章于 2024-09-15 22:03:14 发布
阅读量294 收藏 1
点赞数
文章标签： 设计模式 单一职责原则
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/fkq_2016/article/details/78191774
版权

1. 定义

  • 就一个类而言，应该仅有一个引起它变化的原因。

2. 优点

  • 类的复杂性降低，实现什么职责都有清晰明确的定义。
  • 可读性提高，复杂性降低，那当然可读性提高了。
  • 可维护性提高，可读性提高，那当然更容易维护。
  • 变革引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性和维护性都有非常大的帮助。

3. 缺点

  • 单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或者类设计的是否优良，但是“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异，因而有时候饱受争议。

4. 栗子

  • 单一职责原则适用于接口、类和方法。

  • 接口：

反面教材：

public interface IUserInfo {

    void setUserID(String userID);
    String getUserID();
    void setPassword(String password);
    String getPassword();
    void setUserName(String userName);
    String getUserName();

    boolean changePassword(String oldPassword);
    boolean deleteUser();
    void mapUser();
    boolean addOrg(int orgID);
    boolean addRole(int roleID);

}

问题：用户的属性和用户的行为没有分开。
正面栗子：

//BO(Business Object) 业务对象
public interface IUserBO {
    void setUserID(String userID);
    String getUserID();
    void setPassword(String password);
    String getPassword();
    void setUserName(String userName);
    String getUserName();
}

//Biz(Business Logic) 业务逻辑
public interface IUserBiz {
    boolean changePassword(String oldPassword);
    boolean deleteUser();
    void mapUser();
    boolean addOrg(int orgID);
    boolean addRole(int roleID);
}

正解：两个接口有各自不同的实现类，职责单一，分工明确。
  • 类：
反面教材：

public class ImageLoader {
    //图片缓存
    LruCache<String, Bitmap> mImageCache;
    //线程池，线程数量为CPU的数量
    ExecutorService mExecutorService = Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors());

    public ImageLoader() {
        initImageCache();
    }

    private void initImageCache() {
        //计算可使用的最大内存
        int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
        //取四分之一的可用内存作为缓存
        final int cacheSize = maxMemory / 4;
        mImageCache = new LruCache<String, Bitmap>(cacheSize) {
            @Override
            protected int sizeOf(String key, Bitmap bitmap) {
                return bitmap.getRowBytes() * bitmap.getHeight() / 1024;
            }
        };
    }

    private void displayImage(final String url, final ImageView imageView) {
        imageView.setTag(url);
        mExecutorService.submit(new Runnable() {
            @Override
            public void run() {
                Bitmap bitmap = downloadImage(url);
                if (bitmap == null) {
                    return;
                }
                if (imageView.getTag().equals(url)) {
                    imageView.setImageBitmap(bitmap);
                }
                mImageCache.put(url, bitmap);
            }
        });
    }

    private Bitmap downloadImage(String imageUrl) {
        Bitmap bitmap = null;

        try {
            URL url = new URL(imageUrl);
            final HttpURLConnection conn = (HttpURLConnection) url.openConnection();
            bitmap = BitmapFactory.decodeStream(conn.getInputStream());
            conn.disconnect();

        } catch (IOException e) {
            e.printStackTrace();
        }
        return bitmap;
    }
}

问题：创建线程池、创建LruCache、下载图片、设置图片都放在了一个类，耦合性太强，触一发动全身。
正面栗子：

/**
 * Created by FuKaiqiang on 2017-10-10.
 * 图片缓存类
 */

public class ImageCache {
    //图片Lru缓存
    LruCache<String, Bitmap> mImageCache;

    public ImageCache() {
        initImageCache();
    }

    private void initImageCache() {
        //计算可使用的最大内存
        int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
        //取四分之一的可用内存作为缓存
        final int cacheSize = maxMemory / 4;
        mImageCache = new LruCache<String, Bitmap>(cacheSize) {
            @Override
            protected int sizeOf(String key, Bitmap bitmap) {
                return bitmap.getRowBytes() * bitmap.getHeight() / 1024;
            }
        };
    }

    public void put(String url, Bitmap bitmap) {
        mImageCache.put(url, bitmap);
    }

    public Bitmap get(String url) {
        return mImageCache.get(url);
    }
}

/**
 * Created by FuKaiqiang on 2017-10-10.
 * 图片加载类
 */

public class ImageLoader {
    //图片缓存
    ImageCache mImageCache = new ImageCache();
    //线程池，线程数量为CPU的数量
    ExecutorService mExecutorService = Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors());

    //加载图片
    private void displayImage(final String url, final ImageView imageView) {
        Bitmap bitmap = mImageCache.get(url);
        if (bitmap != null) {
            imageView.setImageBitmap(bitmap);
            return;
        }
        imageView.setTag(url);
        mExecutorService.submit(new Runnable() {
            @Override
            public void run() {
                Bitmap bitmap = downloadImage(url);
                if (bitmap == null) {
                    return;
                }
                if (imageView.getTag().equals(url)) {
                    imageView.setImageBitmap(bitmap);
                }
                mImageCache.put(url, bitmap);
            }
        });
    }

    private Bitmap downloadImage(String imageUrl) {
        Bitmap bitmap = null;
        try {
            URL url = new URL(imageUrl);
            final HttpURLConnection conn = (HttpURLConnection) url.openConnection();
            bitmap = BitmapFactory.decodeStream(conn.getInputStream());
            conn.disconnect();

        } catch (IOException e) {
            e.printStackTrace();
        }
        return bitmap;
    }
}

正解：
1. ImageLoader负责图片加载，ImageCache负责图片缓存，ImageLoader代码量变少，职责清晰。
2. 当缓存相关的逻辑变动时，不需要修改ImageLoader类，当图片加载相关的逻辑变动时，不需要修改缓存处理逻辑。
  • 方法
反面教材：

public interface IUserManager {
    void changeUser(String newUserName, String newHomeAddress, String telNumber);
}

问题：方法职责不清晰，不单一。
正面栗子：

public interface IUserManager {
    void changeUserName(String newsUserName);

    void changeHomeAddress(String newHomeAddress);

    void changeOfficeTel(String telNumber);
}

正解：职责单一，分工明确，你我他都好。

5. 进阶

  • 我们首先看一个接口和它的实现类：
public interface IPhone {
    //拨通电话
    public void dial(String phoneNumber);

    //通话
    public void chat(Object o);

    //通话完毕，挂电话
    public void hangup();
}

问题：它包含两个职责：一个是协议管理，一个是数据传输。
public class Phone implements IPhone {
    @Override
    public void dial(String phoneNumber) {

    }

    @Override
    public void chat(Object o) {

    }

    @Override
    public void hangup() {

    }
}
  • 我们对之进行改进：
public interface IConnectionManager {
    //拨通电话
    public void dial(String phoneNumber);
    //通话完毕，挂电话
    public void hangup();
}

public interface IDataTransfer {
    //通话
    public void chat(Object o);
}

public class ConnectionManager implements IConnectionManager {
    @Override
    public void dial(String phoneNumber) {

    }

    @Override
    public void hangup() {

    }
}

public class DataTransfer implements IDataTransfer {
    @Override
    public void chat(Object o) {

    }
}

问题：
1. 两个接口两个实现类----导致了Phone类要把两个实现类组合在一起才可以使用。
2. 然而组成是一种强耦合关系，有共同的生命周期，这样的耦合关系还不如使用接口实现的方式，而且还正价了类的复杂性，多了两个类。
  • 最终改进如下：
public interface IConnectionManager {
    //拨通电话
    public void dial(String phoneNumber);
    //通话完毕，挂电话
    public void hangup();
}

public interface IDataTransfer {
    //通话
    public void chat(Object o);
}

public class Phone implements IConnectionManager, IDataTransfer {
    @Override
    public void dial(String phoneNumber) {

    }

    @Override
    public void chat(Object o) {

    }

    @Override
    public void hangup() {

    }
}

正解：
1. 这样的设计才是完美的，一个类实现了两个接口，把两个职责融合在一个类中。
2. 你肯定会问这个Phone有两个原因引起变化了呀，是的，但是别忘记了我们是面向接口编程，我们对外公布的是接口而不是实现类。
3. 如果真要实现类的单一职责，我们就必须使用上面的组合模式了，这会引起类间耦合过重、类的数量增加等问题，人为增加了设计的复杂性。
ab_dg_dp
关注
专栏目录
关于密钥管理的几个设计原则
tenfyguo的技术专栏
11-13 1万+
关于密钥管理的几个设计原则 网络安全有赖于密钥管理的有效性，即保证密码的产生，存储，传输和使用的安全性，这就要求对密钥进行有效的管理。 1，任何密码不以明文的方式进行存储，除非是放在足够安全的密码装置内。人工分配的密钥必须以密钥分量方式分别由不同的多个可信任的实体保管,不得直接以明文方式由单个实体掌握,对密码装置的任何操作均无法使得密钥以明文方式出现于密码装置之外; 2，保证
中国银联密钥分发专用终端规范
08-08
银联密钥传输专用POS终端规范 (Specification for TMK Deliver Special Terminal)
单一职责原则【 Single Responsibility Principle】
Lighthouse
02-09 620
前言 最近学习设计模式，看着设计模式的例子很经典，至少自己觉得大部分人都可以理解，在这里分享一下 我是“牛”类，我可以担任多职吗？单一职责原则简称是 SRP，就是三个开通字母的缩写，这个设计原则备受争议的一个原则，只要你想和 人争执、怄气或者是吵架，这个原则是屡试不爽的，如果你是老大，看到一个接口或类是这样…那样…设 计的，你就问一句“你设计的类符合 SRP 原则吗？”，保准立马萎缩掉，而且还一
敏捷开发-单一职责原则
u010029439的博客
12-16 320
https://baike.baidu.com/item/%E5%8D%95%E4%B8%80%E8%81%8C%E8%B4%A3%E5%8E%9F%E5%88%99   单一职责原则（SRP：Single responsibility principle）又称单一功能原则，面向对象五个基本原则（SOLID）之一。它规定一个类应该只有一个发生变化的原因。该原则由罗伯特·C·马丁（Robert ...
面向对象的单一职责原则
learn_to_fly的博客
10-19 425
声明：本系列博客整理来源于《Android源码设计模式解析与实战》，仅作为个人学习总结记录，任何组织和个人不得转载进行商业活动！ 单一职责原则（Simple Responsibility Priciple，SRP） SRP的定义是：就一个类而言，应该仅有一个引起它变化的原因。简单来说，一个类中应该是一组相关性很高的函数、数据的封装。就像秦小波老师在《设计模式之禅》中说的：“这是一个备受争...
设计模式（三）之单一职责原则.zip
02-17
单一职责原则可以使类的复杂度降低，实现什么职责都有清晰明确的定义；类的可读性提高，复杂度降低；可读性提高了，代码就更容易维护；变更（需求是肯定会变）引起的风险（包括测试的难度，以及需要测试的范围）降低...
PHP面向对象五大原则之单一职责原则(SRP)详解
10-18
单一职责原则(SRP)是面向对象设计中的一个基本原则，它要求一个类应该只有一个引起它变化的原因。在PHP等面向对象编程语言中，遵守这一原则可以帮助开发人员编写出结构更清晰、维护性更强的代码。接下来，我们将详细...
简单讲解Java设计模式编程中的单一职责原则
09-02
Java设计模式中的单一职责原则（Single Responsibility Principle，SRP）是面向对象设计的基本原则之一，它的核心思想是：一个类或者一个模块应该只有一个引起它变化的原因。这意味着一个类应该只负责一项职责，使得...
Java设计模式中单一职责原则详解.rar
07-10
其中，"单一职责原则"（Single Responsibility Principle，SRP）是面向对象设计的基本原则之一，也是Java设计模式中的重要组成部分。本篇文章将深入探讨单一职责原则的概念、意义、应用及其在Java编程中的实际运用。...
单一功能原则
个人技术博客
10-23 1167
一，单一功能原则 1.1，对单一功能原则的理解 对于一个类而言，应该仅有一个引起它变化的原因。对象不应该承担太多职责，只有对象的职责比较单一，才能保证对象的高内聚，对象的高内聚有利于对象的重用。 1.2，单一功能原则的优缺点 优点： 单一功能原则有利于对象的稳定。所谓"职责"，就是对象能够承担的责任，并以某种行为方式来执行。对象的职责总是要提供给其他对象调用，从而形成对象与对象的协作，由此产...
1.单一职责原则
上善若水
04-17 4147
1 我是“牛”类，我可以担任多职吗？ 单一职责原则的英文名称是Single Responsibility Principle，简称是SRP。这个设计原则备受争议，只要你想和别人争执、怄气或者是吵架，这个原则是屡试不爽的。如果你是老大，看到一个接口或类是这样或那样设计的，你就问一句：“你设计的类符合SRP原则吗？”保准对方立马“萎缩”掉，而且还一脸崇拜地看着你，心想：“老大确实英明”。这个原则存在
网络安全之秘钥管理规范
春风化雨
05-27 2114
(一) 对主机、系统、网络设备、数据库、管理平台等进行弱口令全面排查，满足口令长度、复杂度要求（至少8位，包含大小写字母、数字、特殊字符），； (二) 严禁口令复用，不同机器、系统、设备等不得使用同一密码； (三) 使用连接工具时，严禁使用记住密码功能； (四) 妥善保管口令，严禁在跳板机上存储用户名、口令等敏感信息，逾期未清理我部将进行清除；严禁明文存储在终端上； (五) 定期（3个月）修改VPN口令，及时与信息科技部同步关停不必要VPN账户； (六) 前期安全检查、审计中发现问题抓紧整改； (七) 加强
密钥管理遵循的原则
jianqu6506的博客
12-22 3659
1、明确密钥管理的策略和机制。 策略是密钥管理的高级指导，机制是实现和执行策略的技术机构和方法。 2、全面安全原则。 必须对密钥生命周期的各个阶段采取妥善的安全管理。 3、最小权利原则。 分配给用户进行事务处理所需要的最少的密钥集合。 4、责任分离原则。 一个密钥应当专职一种功能，不要让一个密钥兼任几个功能。 5、密钥分级原则。 对于一个大的系统，所需要的密钥的种类和职责非常多，需要根据密钥的职责和重要性，把密钥划分成几个级别。 6、密钥更换原则 密钥必须按时更换，否则攻击..
单一原则
Hana_one的博客
10-10 4042
作用： 单一职责原则是最简单的面向对象设计原则，它用于控制类的粒度大小。 定义： 单一职责原则(Single Responsibility Principle, SRP)：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。 单一职责原则告诉我们：一个类不能太“累”（不能做太多的事情）！ 在软件系统中，一个类（大到模块，小到方法）承担的职责越多，它被复...
二十三种设计模式之建造者模式(类比汽车制造厂好理解一些)
apple_64847327的博客
09-12 1364
建造者模式（Builder Pattern）是一种用来构建复杂对象的设计模式，它能够让你分步骤创建复杂对象，并允许你只通过必要的步骤来构建对象。建造者模式是创建型模式之一，它提供了一种创建对象的最佳方式。为了大家更好理解，这里类比汽车制造厂，车辆的组装过程可以看作是建造者模式的应用。汽车的底盘、引擎、内饰等部件（组件）被逐步组装起来，形成一辆完整的汽车（产品）。不同的车型可能需要不同的组装步骤，但组装线（建造过程）保持一致。像这样的类比还有：乐高积木、电脑组装等等。
C++设计模式
最新发布
叫好与叫座虽然不是对立面，但想在同一个作品中达到双重效果很难。
09-15 1331
Abstract Factory 抽象工厂模式：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。Adapter适配器模式：将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工 作。Bridge桥接模式：将抽象部分与它的实现部分分离，使它们都可以独立地变 化。Builder建造者模式：将一个复杂对象的构建与它的表示分离，使得同样的构建 过程可以创建不同的表示。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值