C语言的设计模式-单一职责

C语言的设计模式-单一职责

单一职责原则:

通常的定义是只专注于做一件事和仅有一个引起它变化的原因。对于接口、实现、函数级别往往我们比较容易关注单一职责,大家谈的也比较多,但对于返回值、参数可能不会有太多的人关注。但往往就是这些不符合单一职责原则的设计可能导致一些很难发现的BUG。看看下面这段代码:

pBuf = (byte*)realloc( pBuf, size);
if( pbBuf != NULL )
{
       TODO...
}

可能很多人一眼看上去并没有什么问题,先让我们看看这个库函数的定义:

函数简介
  原型:extern void *realloc(void *mem_address, unsigned int newsize);
  语法:指针名=(数据类型*)realloc(要改变内存大小的指针名,新的大小)。
  功能:先判断当前的指针是否有足够的连续空间,如果有,扩大mem_address指向的地址,并且将mem_address返回,如果空间不够,   先按照newsize指定的大小分配空间,将原有数据从头到尾拷贝到新分配的内存区域,而后释放原来mem_address所指内存区域,同时   返回新分配的内存区域的首地址。即重新分配存储器块的地址。
  返回值:如果重新分配成功则返回指向被分配内存的指针,否则返回空指针NULL。 

正常情况下pBuf是新空间的地址没有任何问题,但我们考虑下如果分配失败了呢,pBuf会被赋值成NULL,pBuf原指向的地址空间就没有指针指向了,造成了内存泄露。这种问题往往很难定位。熟悉realloc机制的人可能对这个问题很不屑,认为高手不会犯这些错误。但我们可以想下有没有办法设计一个好的接口让菜鸟也写出不会出错的代码呢。假设这个库函数的接口是这样的呢:

函数简介
  原型:extern flag realloc(void **ppMem_address, unsigned int newsize);
  语法:返回值 =(数据类型*)realloc(要改变内存大小的指针名,新的大小)。
  返回值:如果重新分配成功则返回指True(ppMem_address保存新分配空间地址),否则返回False(ppMem_address保存老空间地址)。

相信任何一个使用这个接口的人都会写出下面的代码:

if( True == realloc( &pBuf, size))
{
       TODO...
}else{    TODO...}

为什么有人会犯pBuf = (byte*)realloc( pBuf, size);这种错误?因为他只关注了realloc返回值是一个地址,没有关注该返回值还有错误识别的功能,换句话来说这个库函数的返回值不具备单一职责,导致了可能的错误使用。如果使用改进后的接口,因为返回值只有一个判断分配成功与否的功能,相信没有人还会用错。

我们再仔细看看我们新的接口,总觉得似乎有什么地方还是不对,看到void **ppMem_address可能要想一下明白,这个参数既是入参又是出参,它承担了原始地址的输入和新地址的输出,这不又违反了单一职责吗?好吧我们再改进一下:

函数简介
  原型:extern flag realloc(void *pIn_Mem_address,void **ppOut_Mem_address, unsigned int newsize);
  语法:返回值 =(数据类型*)realloc(要改变内存大小的指针名,新的内存指针名,新的大小)。
  返回值:如果重新分配成功则返回指True,否则返回False。

现在这个接口就算一个初次看到的人也应该大概知道什么意思,相信也不会写出什么带BUG的代码,因为函数的参数、返回值都具有单一的功能,通过返回值来判断分配成功与否,通过出参来获取地址。一切看起来都很清晰。

在C库中还有很多类似的函数,如果当初的设计人员能多考虑单一职责,也许现在的系统中就会少了很多隐藏的BUG,接口永远是给别人使用的,一定要把使用者当成傻瓜,也许才能设计出好的接口。

C语言的设计模式-单一职责,布布扣,bubuko.com

时间: 2024-10-17 05:48:21

C语言的设计模式-单一职责的相关文章

小菜学设计模式——单一职责原则

背景 本文标题为什么叫小菜学习设计模式,原因是本文内容主要是学习<大话设计模式>时的笔记摘要部分,当然,并不是记录书中小菜的学习过程,这个完全没有意义,而是指本人学习设计模式的成长之旅. 真诚的希望自己能够从一名小菜成长为一名大鸟! 编写的程序应该满足: 1)可维护 2)可扩展 3)可复用 4)够灵活 废话少说,言归正传,设计模式原则之:单一职责 书面理解 单一职责:就一个类而言,应该仅有一个引起它变化的原因 如果一个类承担职责过多,接等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制

设计模式-单一职责原则

1.单一职责原则 单一职责原则:改变仅因为一个因素 <设计模式之禅>,作者提到有人写了个这样的接口 void changeUser(UserOB userOB,changeOptions option); 不如分开写 void changeUserName(String userName); void changeUserAddress(String address); void changeUserTel(String Tel); 虽然如作者提到的,下面的替代上面的,到底是不是应该替换呢?看

小王和你一起学习系列之设计模式-单一职责原则

单一职责原则,从字面上理解就是做一件事情. 单一职责原则应用的场景包括: 一个接口只做同一类事情 一个类只做同一类事情 一个方法只做一件事情 一段代码只做一件事情 咱们具体分析各个应用场景吧 一.一段代码 ? 一段代码代表一种逻辑.代码是最细粒度,接口.类.方法都是由代码组成的. 二.一个方法 ? 如果方法中的代码逻辑比较简单,哪怕有分支,有不同的逻辑处理,那么也是允许的.如果方法中的代码逻辑很复杂,各种条件判断,如果以后需求发生变更,导致代码发生更改, 修改的时候必然会小心翼翼,生怕改的代码对

设计模式---单一职责模式之装饰模式(Decorator)

前提:"单一职责"模式 在软件组件的设计中,如果责任划分的不清晰,使用继承,得到的结果往往是随着需求的变化,子类急剧膨胀,同时充斥着重复代码,这时候的关键是划清责任 典型模式(表现最为突出) 装饰模式Decorator 桥接模式Bridge 一:装饰模式 (一)概念 装饰模式又叫做包装模式.通过一种对客户端透明的方式来扩展对象的功能,是继承关系的一个替换方案. 装饰模式就是把要添加的附加功能分别放在单独的类中,并让这个类包含它要装饰的对象,当需要执行时,客户端就可以有选择的,顺序的使用

设计模式——单一职责原则

职责过多坏处: 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力. 这种耦合会导致脆弱的设计,当变化发生是,设计会遭受到意想不到的破坏. 单一职责: 软件设计真正要做的许多内容,就是发现职责并把那些职责相互分离. 其实要去判断是否应该分离出类来,也不难,拿就是如果你能够想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责,就应该考虑类的职责的分离. 总结: 在类的职责分离上多思考,做到单一职责,这样你的代码才是真正的易维护,

大话设计模式---单一职责原则

单一职责原则(SRP):就一个类而言,应该仅有一个引起它变化的原因. 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏. 软件设计真正要做的许多内容,就是发现职责并把那些职责互相分离.    如果能够想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责,就应该考虑类的职责分离.

大话设计模式第三章之单一职责原则

单一职责原则指的是就一个类而言,应该仅有一个引起它变化的原因. 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能削弱或者抑制这个类完成其它职责的能力(就像一个程序员  叫他去做医学研究,生物研究,可能会抑制他学设计模式的能力).这种耦合会导致脆弱的设计,当变化发生时,设计会遭到异常不到的破坏(你医学研究久了,设计模式少接触,也就生疏了). 在写一个类的时候,要在类的职责分离上多思考(类的职责搞不清楚,就好像你生病了去找修车的,买菜去学校买),这样代码才是真正的可维护,易扩

设计模式.设计原则-单一职责原则

1:什么情况下 会使用到单一职责原则设计模式? 当同一个类中同时出现业务和属性等代码的时候或者当同一个类中要做多样事情的时候,就需要将其抽象出来,做成多种不同的接口,以便后续方便扩展单一职责:原则要求一个接口或者类只有一个原因引起变化,也就是一个接口或者类只有一个职责,它就负责一件事情 单一原则的好处:类的复杂性降低,实现责任清晰明确可读性高,复杂性降低可维护性提高,可读性提高变更引起风险性降低,变更是必不可少的,如果接口修改,只影响对应的实现类,对其他接口没有影响 如上图所示:Perion类这

设计模式之禅单一职责原则

个人blog 此篇博文地址 :http://www.sanyinchenblog.com/?p=150 最近在看<<设计模式之禅>>感觉这本书很是不错的,demo虽然简单但是确实很明了,感觉很有必要自己再敲一遍 单一职责原则 demo: https://github.com/sanyinchen/UMLDemo 如果一个类有多于一个的动机被改变,那么这个类就具有多于一个的职责.而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因. demo:一个手机类:Iphone.需要用