Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
社区首页 >专栏 >JAVA代码设计六大原则之单一职责

JAVA代码设计六大原则之单一职责

作者头像
用户1205080
发布于 2019-04-25 07:05:01
发布于 2019-04-25 07:05:01
41500
代码可运行
举报
文章被收录于专栏:编码前线编码前线
运行总次数:0
代码可运行

What   就一个类(接口、结构体、方法等等)而言,应该仅有一个引起它变化的原因。

Why

  软件设计真正要做的许多内容,就是发现职责并把那些职责互相分离。单一职责原则可以使类的复杂度降低,实现什么职责都有清晰明确的定义;类的可读性提高,复杂度降低(复杂度降低肯定可读性提高);可读性提高了,代码就更容易维护;变更(需求是肯定会变的,程序员都知道)引起的风险(包括测试的难度,以及需要测试的范围)降低。

How

  需求:实现拍照和播放音乐,那先定义两个功能接口

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
    //具有照相的功能的接口
    interface IPhotograph
    {
        void Photograph();
    }
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
   //具有播放音乐功能的接口
    interface IPlayMusic
    {
        void PlayMusic();
    }

  不遵循单一原则的设计,播放音乐及拍照功能的改变都会引起变化

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
  //实现照相、播放音乐的手机类
    public class MobilePhone : IPhotograph, IPlayMusic
    {
        //拍照
        public void Photograph()
        {
            Console.WriteLine("拍照片");
        }

        //播放音乐
        public void PlayMusic()
        {
            Console.WriteLine("播放音乐");
        }
    }
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
  class Program
    {
        static void Main(string[] args)
        {
            IPlayMusic musicPlayer;
            IPhotograph photographer;

            MobilePhone phone = new MobilePhone();
            musicPlayer = phone;
            photographer = phone;

            //播放音乐
            musicPlayer.PlayMusic();
            //拍照
            photographer.Photograph();
            Console.ReadLine();
        }
    }

  遵循单一原则的设计,引发改变的只有播放音乐功能的变化

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
    //实现播放音乐功能的音乐播放器类
    class MusicPlayer : IPlayMusic
    {
        public void PlayMusic()
        {
            Console.WriteLine("播放音乐");
        }
    }

  遵循单一原则的设计,引发改变的只有摄像功能的变化

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
    //实现照相功能的摄像机类
    class Carmera : IPhotograph
    {
        public void Photograph()
        {
            Console.WriteLine("拍照片");
        }
    }
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
class Program
    {
        static void Main(string[] args)
        {
            IPlayMusic musicPlayer;
            IPhotograph photographer;

            //MobilePhone phone = new MobilePhone();
            //musicPlayer = phone;
            //photographer = phone;

            musicPlayer = new MusicPlayer();
            photographer = new Carmera();

            //播放音乐
            musicPlayer.PlayMusic();
            //拍照
            photographer.Photograph();
            Console.ReadLine();
        }
    }

  糟糕的设计会造成什么样的后果呢?让我们来设想一下,有一天我们的需求发生了变化(需求变化-程序员一生的敌人兼朋友),现有拥有了一部手机,有拍照的功能以及播放音乐的功能,满足了现有的需求,突然有一天觉得简单的拍照功能已经不能满足了,

现在需要能够拍摄高清图片的照相功能,那么怎么办呢?换手机呗,恩找一个支持高清拍照功能的手机。那么好的,需求又变了,现在想要能播放高品质音乐的功能,但是新换的支持高清拍摄的手机的硬件不支持高品质音乐播放,好的,继续换手机,前提是还要

支持拍摄高清照片。相信现在已经能够看出一些端倪了,这两个职责无论哪一个发生了变化,你都要去改变手机,现在只有两个职责,夸张一点说,如果有十个职责呢?那么岂不是要天天换手机,要么就不满足需求变化。

  既然我们看到了糟糕的设计,现在我们回到单一职责上,既然你的需求是拍照片和播放音乐,那么我给你一台相机还有一台音乐播放器,哪个功能需要改变你就换哪个,以后你要换的时候也不必去考虑其他功能,只需要关心引起你自己变化的原因。如果拍照

功能发生改变,我们就去改变照相机,播放音乐功能需要改变我们就去改变音乐播放器。我们不需要去考虑播放高品质音乐是不是会对拍摄高清图片的功能造成影响。

  我们一定要遵循单一职责原则吗?在现有的需求上能做到当然可以去做,但是往往有的时候,需求不是在设计的时候发生改变,而是一定程度之后,你已经有了一定的代码量了,可能修改的开销很高,这个时候就仁者见仁智者见智。就如上述,若是将手机类

拆分,则影响了底层调用的实现,也需要修改,弱是调用的地方太多,那么修改的地方也会很多,若是发布了,改起来也不是很方便,但是当然,也有一定的手法来做这件事情,比如手机类保留,让手机类拥有一个摄像机类对象和一个音乐播放器类对象,然后播放

音乐方法则调用音乐播放器类实例的播放音乐功能,照相功能则调用摄像机类实例的照相功能,这样可以在不影响原有的东西的基础上又遵循原则。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2019-03-31,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 编码前线 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
设计模式-6大原则
如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会消弱或者抑制这个类完成其他职责的能力。
ronixiao
2022/07/25
4910
Golang语言情怀-第19期 Go 语言设计模式-适配器
说起适配器模式,相信很多做android的同学第一印象就是AdapterView的Adapter,那它是干嘛用的呢?为什么要叫adapter呢?要了解这个问题,我们首先来看看适配器模式的定义:
李海彬
2021/01/25
5830
Golang语言情怀-第19期 Go 语言设计模式-适配器
设计模式六大原则——单一职责原则(SRP)
      就一个类而言,应该仅有一个引起它变化的原因。通俗的说,一个类只负责一项职责。
令仔很忙
2018/09/14
8830
设计模式六大原则——单一职责原则(SRP)
设计模式——六大原则[通俗易懂]
1. SingleResponsibilities Principle 定义:就一个类而言,应该仅有一个引起它变化的原因。
全栈程序员站长
2022/08/09
2760
设计模式——六大原则[通俗易懂]
设计模式六大原则(一)--单一职责原则
单一职责原则是设计模式六大原则之一,强调一个类应该仅有一个引起它变化的原因,即每个类应仅负责一项职责。本文通过详细探讨单一职责原则的定义、实现方式、优缺点及其适用场景,揭示了其在软件设计中的核心地位。通过类的拆分、接口设计和方法提炼等策略,单一职责原则有助于降低类的复杂度,提高代码的可读性、可维护性和可扩展性。尽管过度应用可能导致类的数量增加和系统复杂性提升,但其在大型项目和复杂系统中的长期效益显著。
小白的大数据之旅
2024/11/20
1930
设计模式六大原则(一)--单一职责原则
设计模式六大原则(1):单一职责原则
定义:不要存在多于一个导致类变更的原因。通俗的说,即一个类只负责一项职责。 问题由来:类T负责两个不同的职责:职责P1,职责P2。当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障。 解决方案:遵循单一职责原则。分别建立两个类T1、T2,使T1完成职责P1功能,T2完成职责P2功能。这样,当修改类T1时,不会使职责P2发生故障风险;同理,当修改T2时,也不会使职责P1发生故障风险。          说到单一职责原则,很多人都会不屑一顾。因为它太简单了。稍有经验的程序
Angel_Kitty
2018/04/08
6310
设计模式六大原则(一)----单一职责原则
就一个类而言,应该仅有一个引起它变化的原因。应该只有一个职责。如果一个类有一个以上的职责,这些职责就耦合在了一起。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这会导致脆弱的设计。当一个职责发生变化时,可能会影响其它的职责。另外,多个职责耦合在一起,会影响复用性。想要避免这种现象的发生,就要尽可能的遵守单一职责原则。
用户7798898
2021/06/10
3.5K0
多媒体开发
纵观移动市场上的手机,特别是智能手机,大家一定会发现现在的手机已经不仅仅限接听电话、收发短信、浏览网页之类的简单功能了。手机已经发展成一个集照相机、音乐播放器、视频播放器、网页浏览器等功能于一体的智能设备。因此为手机提供音、视频的录制、播放以及照相等功能已经成为软件开发中必不可少的内容。Android原生提供了对MP3、WAV 、MP4和3GP等音频、视频格式支持的组件API,通过这些API和组件我们可以非常容易地实现强大的音频和视频功能。在本章节中我们就结合具体的案例针对Android中的多媒体开发相关的内容进行深入讲解,这部分内容包括音乐的播放、音效的播放、视频的播放、音频的录制以及拍照等功能的实现。
用户9184480
2024/12/17
1420
多媒体开发
设计模式 - 六大设计原则之SRP(单一职责)
单一职责原则(Single Responsibility Principle, SRP)又称单一功能原则,是面向对象的五个基本原则(SOLID)之一。 它规定一个类应该只有一个发生变化的原因。
小小工匠
2023/02/23
5540
设计模式 - 六大设计原则之SRP(单一职责)
设计模式六大原则——开放封闭原则(OCP)
      1、对扩展开放,意味着有新的需求或变化时,可以对现有代码进行扩展,以适应新的情况。
令仔很忙
2018/09/14
1.3K0
架构之基:从根儿上了解设计原则
本文节选自 奔波儿灞取经 的《程序员的必修课》,文中的“我”指原作者奔波儿灞取经。
Cell
2024/06/09
1270
【设计模式 00】六大原则
原则一:若 o1 是 C1 的一个实例化对象, o2 是 C2 的一个实例化对象,如果在使用 C1 的程序中将o1 替换为 o2 而程序行为没有发生变化,那么 C2 应该是 C1 的子类。
JuneBao
2022/10/26
2450
java代码设计的6+1大原则
1.开闭原则(Open Close Principle) 定义:一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。 开放-封闭原则的意思就是说,你设计的时候,时刻要考虑,尽量让这个类是足够好,写好了就不要去修改了,如果新需求来,我们增加一些类就完事了,原来的代码能不动则不动。这个原则有两个特性,一个是说“对于扩展是开放的”,另一个是说“对于更改是封闭的”。面对需求,对程序的改动是通过增加新代码进行的,而不是更改现有的代码。这就是“开放-封闭原则”的精神所在 比如,刚开始需求只是写加法程序,很快在client类中完成后,此时变化没有发生,需求让再添加一个减法功能,此时会发现增加功能需要修改原来这个类,这就违背了开放-封闭原则,于是你就应该考虑重构程序,增加一个抽象的运算类,通过一些面向对象的手段,如继承、动态等来隔离具体加法、减法与client耦合,需求依然可以满足,还能应对变化。此时需求要添加乘除法功能,就不需要再去更改client及加减法类,而是增加乘法和除法子类即可。 绝对的修改关闭是不可能的,无论模块是多么的‘封闭‘,都会存在一些无法对之封闭的变化,既然不可能完全封闭,设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最有可能发生的变化种类,然后构造抽象来隔离那些变化。在我们最初编写代码时,假设变化不会发生,当变化发生时,我们就创建抽象来隔离以后发生同类的变化。 我们希望的是在开发工作展开不久就知道可能发生的变化,查明可能发生的变化所等待的时候越长,要创建正确的抽象就越困难。开放-封闭原则是面向对象设计的核心所在,遵循这个原则可以带来面向对象技术所声称的巨大好处,也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现出现频繁变化的那些部分做出抽象,然而对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意,拒绝不成熟的抽象和抽象本身一样重要。开放-封闭原则,可以保证以前代码的正确性,因为没有修改以前代码,所以可以保证开发人员专注于将设计放在新扩展的代码上。 简单的用一句经典的话来说:过去的事已成历史,是不可修改的,因为时光不可倒流,但现在或明天计划做什么,是可以自己决定(即扩展)的。
lyb-geek
2018/07/26
9720
设计模式 -- 装饰模式
现需要定制几个品牌的手机,如iPhone、xiaomi、huawei等,根据其功能不同进行定制,再不断的迭代中手机功能需要不停的升级
xy_ss
2023/11/22
1840
设计模式 -- 装饰模式
设计模式六大原则: 一个萝卜一个坑 -- 单一职责原则
设计模式流传江湖许久,据说有 23 式,而万物归宗皆有其律,这些繁杂的模式总结出来就是如下 6 大原则。
张拭心 shixinzhang
2022/05/10
1530
设计模式六大原则: 一个萝卜一个坑 -- 单一职责原则
设计模式的六大原则
文章介绍了设计模式中的六大原则:开闭原则、里氏替换原则、依赖倒置原则、接口隔离原则、单一职责原则、迪米特法则。这些原则对于项目开发有很好的指导作用,可以降低维护难度,提高代码可读性。
用户1134788
2017/12/27
1K0
设计模式六大原则
  单一职责原则又称为单一功能原则,即不要存在多于一个导致类变更的原因。通俗的说,即一个类只负责一项职责。
那一叶随风
2018/08/22
2880
设计模式六大原则
设计模式的六大原则
原则思想:一个方法只负责一件事情。 描述:单一职责原则很简单,一个方法 一个类只负责一个职责,各个职责的程序改动,不影响其它程序。 这是常识,几乎所有程序员都会遵循这个原则。 优点:降低类和类的耦合,提高可读性,增加可维护性和可拓展性,降低可变性的风险。
用户7798898
2022/05/09
1.3K0
设计模式六大原则
上篇文章说了工厂模式的单例模式和创建模式,单例模式如何在懒加载的情况下保证线程安全性,创建模式通过接口和抽象类,来完成开闭原则。
用户9919783
2022/12/14
4080
初探设计模式六大原则
我想用贴近生活的语句描述一下自己对六种原则的理解。也就是不做专业性的阐述,而是描述一种自己学习后的理解和感受,因为能力一般而且水平有限,也许举的例子不尽妥当,还请谅解
啦啦啦321
2019/11/02
3720
相关推荐
设计模式-6大原则
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
本文部分代码块支持一键运行,欢迎体验
本文部分代码块支持一键运行,欢迎体验