我是靠谱客的博主 务实鞋垫,最近开发中收集的这篇文章主要介绍设计模式(三)之单一职责原则,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

单一职责原则:

官方给的说法是:就一个类而言,应该仅有一个因其他变化的原因。

说白了就是,一个类只负责一项职责。

最简单也是最难的原则。难处在于对职责进行划分。单一职责原则提出了一个编写程序的标准,用“职责”或“变化原因”来衡量接口或类设计得是否优良,但是“职责”和“变化原因”都是不可度量的,因项目而异,因环境而异。

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

下边使用手机来举例:这个手机我们需要实现播放音乐和拍照片的功能。

不遵循单一设计模式:

主文件:Progam.cs

using System;
namespace simple
{
    class Program
    {
        static void Main(string[] args)
        {
            Imusic music = new Totol();
            Iphoto photo = new Totol();
  
            music.PutMusic();
            photo.PutPhoto();
  
            Console.ReadLine();
        }
    }
}

接口文件:Iphoto.cs

namespace simple
{
    interface Iphoto
    {
        /// <summary>
        /// 拍照片方法
        /// </summary>
        void PutPhoto();
    }
}

接口文件:Imusic

namespace simple
{
    interface Imusic
    {
        /// <summary>
        /// 播放音乐方法
        /// </summary>
        void PutMusic();
    }
}

子类文件:Totol.cs用于实现上面两个接口

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
  
namespace simple
{
    public class Totol: Iphoto,Imusic
    {
        public void PutPhoto()
        {
            Console.WriteLine("拍照片");
        }
  
        public void PutMusic()
        {
            Console.WriteLine("放音乐");
        }
    }
}

上边的设计显然不符合单一职责原则,totol类中有两个功能,也就是说,我们调用其中任何一个功能的时候,都会引起这个类的变化。

下边我们使用单一职责原则来实现:说的很高大上,说白了就是将totol类中的两个功能分开。

主文件:Program.cs

using System;
  
namespace simple
{
    class Program
    {
        static void Main(string[] args)
        {
            //Imusic music = new Totol();
            //Iphoto photo = new Totol();
  
            Music music = new Music();
            Photo photo = new Photo();
  
            music.PutMusic();
            photo.PutPhoto();
  
            Console.ReadLine();
        }
    }
}

接口文件Iphoto.cs

namespace simple
{
    interface Imusic
    {
        /// <summary>
        /// 播放音乐方法
        /// </summary>
        void PutMusic();
    }
}

Imusic.sc

namespace simple
{
    interface Imusic
    {
        /// <summary>
        /// 播放音乐方法
        /// </summary>
        void PutMusic();
    }
}

子类Music.cs

using System;
namespace simple
{
    class Music:Imusic
    {
        public void PutMusic()
        {
            Console.WriteLine("放音乐");
        }
    }
}

子类:Photo.cs

using System;
namespace simple
{
    class Photo:Iphoto
    {
        public void PutPhoto()
        {
            Console.WriteLine("拍照片");
        }
    }
}

以上的代码只是一个比较弱智的小例子。理解大概意思就好。

可以用上边的例子继续举例,我们手机最基础的功能只要拍照和放音乐,现在我需要手机可以拍摄有声Gif动图,并且可以播放,那么再修改上,不遵循单一职责原则的类可能就会出现很多意向不到的问题。但是如果他是两个类的话,可能我们修改起来的复杂程度,需要考虑的限制就没有那么多。这个就是单一职责原则的好处。

但是这篇文章最开始的部分也提到了:这个最难的部分还是职责的分离,往往很多项目的奇葩需求和奇葩逻辑,我们没有办法将其分的清楚。所以这个只能尽量遵守,为后期代码的开发做一个好的铺垫。

因为,需求是会变的。

有好的建议,请在下方输入你的评论。

欢迎访问个人博客
https://guanchao.site

欢迎访问小程序:

在这里插入图片描述

最后

以上就是务实鞋垫为你收集整理的设计模式(三)之单一职责原则的全部内容,希望文章能够帮你解决设计模式(三)之单一职责原则所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(47)

评论列表共有 0 条评论

立即
投稿
返回
顶部