脚本宝典收集整理的这篇文章主要介绍了PHP 杂谈《重构-改善既有代码的设计》之五 简化函数调用,脚本宝典觉得挺不错的,现在分享给大家,也给大家做个参考。
思维导图
介绍
前几篇
系列文章,我比较关注的是<PHP
杂谈《重构-改善既有代码的设计》之一 重新组织你的函数>,但是我
觉得我还是没有说清楚,我自己也有很多不理解的地方,而且这篇是我的第一篇这方面的
文章,有很多的纰漏,所以我会经常性的去做
修改,如果大家有好的意见不妨告知一、二。 今天谈得是“接口”,此接口非“Interface”,而是
一个统称。我们一般可以把供
别人使用的
函数或者url
(一般是用于提供数据)叫接口。——可能还有别的
意思,毕竟我现在还属于“
菜鸟”,如果有理解上的
错误,请指正。 我们
知道“容易被理解和被使用的接口”,是开发良好面向对象软件的关键。——本文将介绍“使接口变得更简洁易用”的重构手法。 题外话:
如果大家觉得我这篇
文章太长,看起来麻烦的话,建议大家”就看
图片和
粗体的
文字“。
昨天,“old“博友给我留言,我以前也没仔细考虑过,这次我也想了想。留言
内容是:
我个人觉得,很多事情只有我们去关注过,才能知道它的
价值。
至于
简单,重构的目地也是为了简单和易理解性。
至于执着,我觉得在技
术上,我们很多时候需要这种执着,即使你过后觉得你错了,但是我们
在这之间还是会有所收获。我们只有
经历过很多次的磨合(这种磨合有正确的也有
错误的),我们才能知道它的价值,我们才能收获到我们需要的东西。
至于利益,”Old“是不是指
公司利益,恩,确实是,很多时候我们在编码的
过程中,需要赶
进度,还有我们在重构中也会有一些
错误出来,所以我的建议是,在开发之初,你就要在设计和重构中,
不断进行磨合,不要觉得浪费时间,很多时候,好的结构能加速你的开发。
专业术语
<img tITle="PHP 杂谈《重构-改善既有代码的设计》之五 简化函数调用" alt="PHP 杂谈《重构-改善既有代码的设计》之五 简化函数调用" src="https://files.js-code.cc/file_images/article/201205/2012050721441925.png">
41926.png">
41927.png">
41928.png">
41929.png">
@H_304_79@
41931.png">
状况:如果
函数的
名称未能揭示
函数的
用途,那么
修改函数名称。
41932.png">
动机:
我极力提倡的一种编程风格就是将复杂的处理过程分解成小
函数。但是如果小
函数的命名不好,这会使你费劲周折却弄不清楚这些小
函数各自的用途。 给
函数命名的
一个好办法:考虑
应该给这个
函数写上一句
怎样的注释 -——> 想办法将注释变成
函数的
名称。 起
一个好
名称并不容易,需要经验。——要想成为
一个真正的编程高手,“起
名称”的水平至关
重要。 如果你看到
一个函数名称不能很好的表达它的用途,应该马上加以
修改。 Ex
ample:
41933.png">
41934.png">
41935.png">
41936.png">
41937.png">
41938.png">
Add Parameter
状况:某个
函数需要从
调用端得到更多的信息,那么为此
函数添加一个参数,让该参数带进
函数所需信息。 动机:
1、Add Parameter 是
一个很常用的重构手法。
2、
修改过的
函数需要一些过去没有的信息,因此你需要给
函数添加一个参数。
3、除了Add Parameter外,只要有可能,其他选择都比“Add Parameter”要好,因为有可能其他选择不会
增加参数列的长度。——过长的参数列会使程序员记不住那么
多参数。
41939.png">
Remove Parameter
状况:
函数本体不再需要某个参数,那么将该参数
去除。
动机:
1、参数指出
函数信息,不同参数代表不同意义。
函数调用这必须为每
一个参数操心该传什么东西进去。——如果不去掉参数,那就为每一次
调用多费一份心。
2、如果你发现有很多
调用者,那么为了不让
调用者操心,你可以这样做,把要移除的参数设置为某个
默认值(如null),这样
调用者只传那些没有
默认值的参数。
41940.png">
Separate Query
From Modifier
状况:
如果某个
函数既返回对象的状态值,又
修改(副作用)对象状态(
state),那么
。
41941.png">
Example:
41942.png">
41943.png">
41944.png">
Parameterize Method
状况:
如果若干
函数做了类似的工作,但在
函数本体中包含了不同的值,那么
建立单一函数,以参数表达那些不同的值
。
动机:
1、一般是因为有少数几个值不同,所以建立了几个相似的
函数。
2、分离的
函数替换为
一个统一的
函数,通过参数来处理那些变化情况,以简化问题。
3、
去除重复的
代码,
提高灵活性。——可以使用这个参数处理其他变化情况。
41945.png">
Example:
41946.png">
41947.png">
41948.png">
Replace Parameter with E
xplicit Methods
状况:
你有
一个函数,其内完全取决于参数值而采取不同的反应,那么
针对该参数的每个值,建立一个独立的函数
。
1、如果某个参数有离散值,而
函数内又以条件式检查这些参数值,并根据不同的参数值
做出不同的反应,那么就应该使用本次重构。
2、可以获得好处:“编译期
代码检查”,“接口更清楚”(如果用参数值决定
函数行为,那么
函数用户不但需要观察该
函数,而且还要判断参数
是否“合法化”。——而合法的参数,很少在文档中提到,必须通过上下文,才能判断)
3、不考虑“编译期
检验”的好处,为了
获取一个清晰的接口,我们也值得这么做。
41949.png">
Example:
41950.png">
41951.png">
41952.png">
41951.png">
41953.png">
状况:
如果你从某个对象中取出若干值,将它们作为某一次
函数调用中的参数,那么
改使用(传递)整个对象
。
动机:
1、参数列更稳固;
2、提高
代码的
可读性;——过长的参数列很难使用,因为
调用者和被
调用者都必须记住这些参数的用途。
41954.png">
Example:
41955.png">
41951.png">
41956.png">
Replace Parameter with Methods
状况:
如果对象
调用某个
函数,并将所得结果做为参数,传递给另
一个函数(接受参数的
函数也有
调用前
一个函数的能力),那么
。
动机:
1、如果
函数通过其他途径获得参数值,那么它就不应该通过参数取得该值。
2、过长的参数列会
增加程序阅读者的理解难度,因此我们应该尽可能的缩短参数列的长度。
3、
方法:看看“参数接受端”是否可以通过“与
调用端相同的计算”来取得参数携带值。
4、如果
函数调用端通过对象内部的另
一个函数来计算参数,并在计算过程中“未曾引用
调用端的其他参数”,那么就可以将这个计算过程转移到被
调用端内,从而
去除该项参数。
Example:
41957.png">
41951.png">
41958.png">
Introduce Parameter Object
状况:
某些参数总是很自然地同时出现,那么
以一个对象取代这些参数
。
41959.png">
1、一组参数可能有几个
函数同时使用,这些
函数可能隶属于同
一个class,也可能隶属于不同的classes。——这样的一组参数就是所谓的Data Clump(数据泥团)。
2、我们可以运用
一个对象包装所有这些数据,再以对象取代Data Clump。——目地:哪怕只是为了把这些数据组织在一起,这样做也是值得的。
3、本项重构的价值在于“缩短了参数列的长度”。此外,新对象所定义的访问
函数(accessors)还可以使
代码更具一致性。——这又进一步降低了
代码的理解难度和
修改难度。
4、本项重构还可以带给你更多好处。——当你把这些参数组织到一起之后,往往很快可以发现“可被移植新建class“的行为。——减少重复
代码。
Example:
41960.png">
41961.png">
41962.png">
Remove Setting Method
你的class中的
某个值域,应该在对象初创时被设置,然后就不再
改变,那么
去掉该值域的所有设置函数(setter)。
41963.png">
动机:
1、如果你为某个值域提供了设置
函数(setter),这就暗示了这个值域可以被改变。
2、如果你不希望在对象初创之后,此值域还有
机会改变,那就不要为它提供设置
函数。——这样你的意图会更加清晰,并且可以排除其值被
修改的可能性。
Example:
41964.png">
41965.png">
41966.png">
41967.png">
41968.png">
41969.png">
41970.png">
Hide Method
状况:
如有有
一个函数,从来没有被其他class用到,那么
将这个函数设置为private
。
41971.png">
1、重构往往促使你
修改“
函数的可见度“。——时刻检查可被隐藏的
函数。
2、经常检查有没有可能降低某个
函数的可见度(使它私有化)。
——>当你在另
一个class中移除对某个
函数的
调用时,就应该检查。
Replace Constructor with Factory Method
状况:
如果你希望在创建对象时不仅仅是对它做简单的构件动作,那么
将__construct(构造函数)替换为factory method
。
动机:
Example:
41972.png">
41973.png">
41974.png">
41975.png">
41976.png">
41977.png">
41978.png">
接着来:
41979.png">
41980.png">
Replace Error Code with Exception
如果某个
函数返回
一个特定的
代码(s
PEcial code),用以表示某种
错误情况,那么
改用异常(Exception)
。
动机:
清楚的将”普通程序“和”
错误处理“分开,这使的程序更容易”理解“。
41981.png">
Example:
41982.png">
41983.png">
41984.png">
41985.png">
conclusion
把我每一次的收获与大家
分享,如果大家有那么一丁点的收获,也让我高兴不已。还有如在
文章中有
错误,望请指点一、二。
我不知道是不是找错地方了,有博友留言说“
博客园里主要盛行C
#”,看得人是不是主要以
PHP程序员为主?还有很少有人给我留言,也很少有人指出我
文章中的
错误(难道我的
文章中真的没有
错误吗?),昨天”@四眼蒙面侠“给我留了言,我在与他的交谈中收获甚多,也感谢的他的批评指正,也希望能跟大家多交流。
脚本宝典总结
以上是脚本宝典为你收集整理的PHP 杂谈《重构-改善既有代码的设计》之五 简化函数调用全部内容,希望文章能够帮你解决PHP 杂谈《重构-改善既有代码的设计》之五 简化函数调用所遇到的问题。
如果觉得脚本宝典网站内容还不错,欢迎将脚本宝典推荐好友。
本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。