闲谈设计模式之单一原则

2024-02-20 20:20

本文主要是介绍闲谈设计模式之单一原则,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

闲谈设计模式之单一原则

  • 闲谈设计模式序论
  • 单一原则(Single Responsibility Principle)
  • 代码示例探讨SRP
    • 常见动物呼吸案例
    • 结合Android源码设计模式
  • 总结

闲谈设计模式序论

闲谈设计模式是本人通过书籍、实际开发中总结所写,闲谈设计模式会以Java、Kotlin、Android源码进行分析讲解。如果讲述不清楚或者存有争议疑问希望从大读者留言一起探讨

单一原则(Single Responsibility Principle)

单一原则:单一原则俗称SRP,其含义代表一个类应该仅有一个函数或者一个地方使其发生变化,近似的可以将一个类看成高度相关的一组函数或者一组组件,如果有多个地方可以引起其发生变化,那么这个类最终行为将变得不可预测,这对程序的把控风险大大提高。

  • 优点:通过遵守SRP可以避免上帝类的创建,从而减少类的臃肿维护成本。
  • 缺点:SRP的界限没有一个统一,基本都是由人而定,每个人的经验不一导致容易出现多余类的创建。

代码示例探讨SRP

常见动物呼吸案例

一个动物类有一个呼吸的方法代码如下:

public class Animal {//有一个动物类,里面有一个呼吸的方法public void breathe(@NotNull String animal) {Log.i("SRP",(animal + "呼吸空气"));}
}

上述代码仅仅适用于直接呼吸空气的动物,但是如果职责扩散了,呼吸的方法行为变得更细致细腻了呢很明显上述方法则不适用了。例如鱼这个种类那么代码又可以拓展成这样子来写了

public class Animal {public void breathe(@NotNull String animal) {if ("鱼".equals(animal)) {Log.i("SRP",(animal + "呼吸水"));} else {Log.i("SRP",(animal + "呼吸空气"));}}
}

但是这样子的写法仅仅就对了吗?通过不断的添加添加判断会使得breathe这个方法变得更容于更沉重了。
还有一种做法就是直接继承Animal重写breathe方法,但是成千上万个动物需要示例的时候是否需要在一一创建呢显然不合理,避免类的冗余创建其实我们可以通过接口方式去实现代码如下:

public class Animal {private String nameAnimal;private Breathe breathe;private interface Breathe{void breathe();}public Animal(@NotNull String nameAnimal) {this.nameAnimal = nameAnimal;}public void setBreathe(Breathe breathe) {this.breathe = breathe;}public void breathe(){if (breathe!=null) breathe.breathe();}
}

通过使用Breathe接口使得类的创建避免了冗余,对于需要每个动物的呼吸行为则通过实现Breathe接口,区分得出breathe的行为。

结合Android源码设计模式

先来看一组UML图

public class ImageLoader {//获取图片缓存ImageCache imageCache = new ImageCache();//线程池数量为cpu数量ExecutorService mExecutorService = Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors());//回调ui线程Handler mUiHandler = new Handler(Looper.getMainLooper());private void updateImageView(final ImageView imageView,final Bitmap bitmap){mUiHandler.post(() -> {imageView.setImageBitmap(bitmap);});}public void displayImage(final String url,final ImageView imageView){Bitmap bitmap = imageCache.get(url);if (bitmap!=null){updateImageView(imageView,bitmap);}else {mExecutorService.submit(() -> {Bitmap downloadBitmap = downloadImage(url);if (downloadBitmap==null)return;if (imageView.getTag().equals(url)){updateImageView(imageView,bitmap);}imageCache.put(url,bitmap);});}}private Bitmap downloadImage(String url) {Bitmap bitmap = null;try{URL url1 = new URL(url);HttpURLConnection connection = (HttpURLConnection) url1.openConnection();bitmap = BitmapFactory.decodeStream(connection.getInputStream());connection.disconnect();}catch (Exception e){}return bitmap;}
}public class ImageCache {LruCache<String, Bitmap> mImageCache;public ImageCache() {initImageCache();}private void initImageCache() {final int maxMermory = (int) (Runtime.getRuntime().maxMemory()/1024);final int cacheSize = maxMermory/4;mImageCache = new LruCache<String, Bitmap>(cacheSize){@Overrideprotected int sizeOf(String key, Bitmap value) {return value.getRowBytes()*value.getHeight()/1024;}};}public void put(String url,Bitmap bitmap){mImageCache.put(url, bitmap);}public Bitmap get(String url){return mImageCache.get(url);}
}

结合Android设计模式开篇源码,以及时序图可以得到遵循单一原则可以使得这样加载图片得一个工具类,维护起来十分简易,ImageCache只负责缓存图片,而ImageLoader则负责加载图片,充分体验单一原则的好处使得代码既不冗余并便于维护。

总结

合理的使用单一原则可以使得程序更好的维护,使得代码逻辑分层更加清晰可见,对某个单一功能仅仅维护其所在位置;滥用单一原则存在冗余类的创建,二逻辑分层可能会出现模糊甚至不可阅,三加重代码维护成本。

这篇关于闲谈设计模式之单一原则的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/729426

相关文章

在JS中的设计模式的单例模式、策略模式、代理模式、原型模式浅讲

1. 单例模式(Singleton Pattern) 确保一个类只有一个实例,并提供一个全局访问点。 示例代码: class Singleton {constructor() {if (Singleton.instance) {return Singleton.instance;}Singleton.instance = this;this.data = [];}addData(value)

JVM内存调优原则及几种JVM内存调优方法

JVM内存调优原则及几种JVM内存调优方法 1、堆大小设置。 2、回收器选择。   1、在对JVM内存调优的时候不能只看操作系统级别Java进程所占用的内存,这个数值不能准确的反应堆内存的真实占用情况,因为GC过后这个值是不会变化的,因此内存调优的时候要更多地使用JDK提供的内存查看工具,比如JConsole和Java VisualVM。   2、对JVM内存的系统级的调优主要的目的是减少

PHP最长单一子串

<?php//方法一$s='abcccddddddcdefg';$max='';while($s!=''){$i=0; while($i<strlen($s) && $s[$i]==$s[0]) $i++;if ($i>strlen($max)){$max=substr($s,0,$i);} $s=substr($s,$i);}echo $m

设计模式之工厂模式(通俗易懂--代码辅助理解【Java版】)

文章目录 1、工厂模式概述1)特点:2)主要角色:3)工作流程:4)优点5)缺点6)适用场景 2、简单工厂模式(静态工厂模式)1) 在简单工厂模式中,有三个主要角色:2) 简单工厂模式的优点包括:3) 简单工厂模式也有一些限制和考虑因素:4) 简单工厂模式适用场景:5) 简单工厂UML类图:6) 代码示例: 3、工厂方法模式1) 在工厂方法模式中,有4个主要角色:2) 工厂方法模式的工作流程

C#设计模式(1)——单例模式(讲解非常清楚)

一、引言 最近在学设计模式的一些内容,主要的参考书籍是《Head First 设计模式》,同时在学习过程中也查看了很多博客园中关于设计模式的一些文章的,在这里记录下我的一些学习笔记,一是为了帮助我更深入地理解设计模式,二同时可以给一些初学设计模式的朋友一些参考。首先我介绍的是设计模式中比较简单的一个模式——单例模式(因为这里只牵涉到一个类) 二、单例模式的介绍 说到单例模式,大家第一

漫谈设计模式 [12]:模板方法模式

引导性开场 菜鸟:老大,我最近在做一个项目,遇到了点麻烦。我们有很多相似的操作流程,但每个流程的细节又有些不同。我写了很多重复的代码,感觉很乱。你有啥好办法吗? 老鸟:嗯,听起来你遇到了典型的代码复用和维护问题。你有没有听说过“模板方法模式”? 菜鸟:模板方法模式?没听过。这是什么? 老鸟:简单来说,模板方法模式让你在一个方法中定义一个算法的骨架,而将一些步骤的实现延迟到子类中。这样,你可

漫谈设计模式 [9]:外观模式

引导性开场 菜鸟:老鸟,我最近在做一个项目,感觉代码越来越复杂,我都快看不懂了。尤其是有好几个子系统,它们之间的调用关系让我头疼。 老鸟:复杂的代码确实让人头疼。你有没有考虑过使用设计模式来简化你的代码结构? 菜鸟:设计模式?我听说过一些,但不太了解。你觉得我应该用哪个模式呢? 老鸟:听起来你的问题可能适合用**外观模式(Facade Pattern)**来解决。我们可以一起探讨一下。

设计模式大全和详解,含Python代码例子

若有不理解,可以问一下这几个免费的AI网站 https://ai-to.cn/chathttp://m6z.cn/6arKdNhttp://m6z.cn/6b1quhhttp://m6z.cn/6wVAQGhttp://m6z.cn/63vlPw 下面是设计模式的简要介绍和 Python 代码示例,涵盖主要的创建型、结构型和行为型模式。 一、创建型模式 1. 单例模式 (Singleton

漫谈设计模式 [6]:适配器模式

引导性开场 菜鸟:老鸟,我最近在项目中遇到一个问题,我们的系统需要集成一个新的第三方库,但这个库的接口和我们现有的代码完全不兼容。我该怎么办? 老鸟:这是个常见的问题,很多开发者都会遇到这种情况。你有没有听说过适配器模式? 菜鸟:适配器模式?没有,能详细说说吗? 老鸟:当然可以!这就是我们今天要讨论的主题。适配器模式是一个设计模式,可以帮助我们解决你现在遇到的问题。 渐进式介绍概念 老

2 观察者模式(设计模式笔记)

2 观察者模式(别名:发布-订阅) 概念 定义对象间的一种一对多的依赖关系,当一个对象状态发生变化时,所以依赖于它的对象都得到通知并被自动更新。 模式的结构与使用 角色 主题(Subject)观察者(Observer)具体主题(ConcreteSubject)具体观察者(ConcreteObserver) 结构 Subject依赖于Observer最重要!!! package