PHP Talk "Refactoring - Improving the Design of Existing Code" Part 5 Simplifying Function Calls_PHP Tutorial

思维导图


介绍

　　前几篇系列文章，我比较关注的是，但是我觉得我还是没有说清楚，我自己也有很多不理解的地方，而且这篇是我的第一篇这方面的文章，有很多的纰漏，所以我会经常性的去做修改，如果大家有好的意见不妨告知一、二。

　　今天谈得是“接口”，此接口非“Interface”，而是一个统称。我们一般可以把供别人使用的函数或者url（一般是用于提供数据）叫接口。——可能还有别的意思，毕竟我现在还属于“菜鸟”，如果有理解上的错误，请指正。

　　我们知道“容易被理解和被使用的接口”，是开发良好面向对象软件的关键。——本文将介绍“使接口变得更简洁易用”的重构手法。

题外话：
　　如果大家觉得我这篇文章太长，看起来麻烦的话，建议大家”就看图片和粗体的文字“。
　　昨天，“old“博友给我留言，我以前也没仔细考虑过，这次我也想了想。留言内容是：

我个人觉得，很多事情只有我们去关注过，才能知道它的价值。
　　至于简单，重构的目地也是为了简单和易理解性。
　　至于执着，我觉得在技术上，我们很多时候需要这种执着，即使你过后觉得你错了，但是我们在这之间还是会有所收获。我们只有经历过很多次的磨合（这种磨合有正确的也有错误的），我们才能知道它的价值，我们才能收获到我们需要的东西。
　　至于利益，”Old“是不是指公司利益，恩，确实是，很多时候我们在编码的过程中，需要赶进度，还有我们在重构中也会有一些错误出来，所以我的建议是，在开发之初，你就要在设计和重构中，不断进行磨合，不要觉得浪费时间，很多时候，好的结构能加速你的开发。

专业术语

 

 

 

 

 

 

 

Rename Method

状况：如果函数的名称未能揭示函数的用途，那么修改函数名称。

动机：
　　我极力提倡的一种编程风格就是将复杂的处理过程分解成小函数。但是如果小函数的命名不好，这会使你费劲周折却弄不清楚这些小函数各自的用途。

　　给函数命名的一个好办法：考虑应该给这个函数写上一句怎样的注释 -——> 想办法将注释变成函数的名称。

　　起一个好名称并不容易，需要经验。——要想成为一个真正的编程高手，“起名称”的水平至关重要。

　　如果你看到一个函数名称不能很好的表达它的用途，应该马上加以修改。

Example:

 

 

 

Add Parameter

状况：某个函数需要从调用端得到更多的信息，那么为此函数添加一个参数，让该参数带进函数所需信息。

动机：
　　1、Add Parameter 是一个很常用的重构手法。
　　2、修改过的函数需要一些过去没有的信息，因此你需要给函数添加一个参数。
　　3、除了Add Parameter外，只要有可能，其他选择都比“Add Parameter”要好，因为有可能其他选择不会增加参数列的长度。——过长的参数列会使程序员记不住那么多参数。

Remove Parameter

状况：函数本体不再需要某个参数，那么将该参数去除。
动机：
　　1、参数指出函数信息，不同参数代表不同意义。函数调用这必须为每一个参数操心该传什么东西进去。——如果不去掉参数，那就为每一次调用多费一份心。
　　2、如果你发现有很多调用者，那么为了不让调用者操心，你可以这样做，把要移除的参数设置为某个默认值（如null），这样调用者只传那些没有默认值的参数。

Separate Query from Modifier

 

状况：如果某个函数既返回对象的状态值，又修改（副作用）对象状态（state），那么建立两个不同的函数，其中一个负责查询，另一个负责修改。

 

 Example:

 

 Parameterize Method

 

状况：如果若干函数做了类似的工作，但在函数本体中包含了不同的值，那么建立单一函数，以参数表达那些不同的值。

动机：

　　1、一般是因为有少数几个值不同，所以建立了几个相似的函数。

　　2、分离的函数替换为一个统一的函数，通过参数来处理那些变化情况，以简化问题。

　　3、去除重复的代码，提高灵活性。——可以使用这个参数处理其他变化情况。

 

Example：

 

 Replace Parameter with Explicit Methods

 

状况：你有一个函数，其内完全取决于参数值而采取不同的反应，那么针对该参数的每个值，建立一个独立的函数。

动机：

　　1、如果某个参数有离散值，而函数内又以条件式检查这些参数值，并根据不同的参数值做出不同的反应，那么就应该使用本次重构。

　　2、可以获得好处：“编译期代码检查”，“接口更清楚”（如果用参数值决定函数行为，那么函数用户不但需要观察该函数，而且还要判断参数是否“合法化”。——而合法的参数，很少在文档中提到，必须通过上下文，才能判断）

　　3、不考虑“编译期检验”的好处，为了获取一个清晰的接口，我们也值得这么做。

 

Example:

 

 

 Preserve Whole Object

 

状况：如果你从某个对象中取出若干值，将它们作为某一次函数调用中的参数，那么改使用（传递）整个对象。

 动机：

　　1、参数列更稳固;

　　2、提高代码的可读性;——过长的参数列很难使用，因为调用者和被调用者都必须记住这些参数的用途。

Example：

 

 Replace Parameter with Methods

 

状况：如果对象调用某个函数，并将所得结果做为参数，传递给另一个函数（接受参数的函数也有调用前一个函数的能力），那么让参数接受者去除该项参数，并直接调用前一个函数。

 

动机：

　　1、如果函数通过其他途径获得参数值，那么它就不应该通过参数取得该值。

　　2、过长的参数列会增加程序阅读者的理解难度，因此我们应该尽可能的缩短参数列的长度。

　　3、方法：看看“参数接受端”是否可以通过“与调用端相同的计算”来取得参数携带值。

　　4、如果函数调用端通过对象内部的另一个函数来计算参数，并在计算过程中“未曾引用调用端的其他参数”，那么就可以将这个计算过程转移到被调用端内，从而去除该项参数。

 

Example：

 

 Introduce Parameter Object

 

状况：某些参数总是很自然地同时出现，那么以一个对象取代这些参数。

 

动机：

　　1、一组参数可能有几个函数同时使用，这些函数可能隶属于同一个class，也可能隶属于不同的classes。——这样的一组参数就是所谓的Data Clump（数据泥团）。

　　2、我们可以运用一个对象包装所有这些数据，再以对象取代Data Clump。——目地：哪怕只是为了把这些数据组织在一起，这样做也是值得的。

　　3、本项重构的价值在于“缩短了参数列的长度”。此外，新对象所定义的访问函数（accessors）还可以使代码更具一致性。——这又进一步降低了代码的理解难度和修改难度。

　　4、本项重构还可以带给你更多好处。——当你把这些参数组织到一起之后，往往很快可以发现“可被移植新建class“的行为。——减少重复代码。

 

Example：

 

 

 Remove Setting Method

 

状况：你的class中的某个值域，应该在对象初创时被设置，然后就不再改变，那么去掉该值域的所有设置函数（setter）。

动机：

　　1、如果你为某个值域提供了设置函数（setter），这就暗示了这个值域可以被改变。

　　2、如果你不希望在对象初创之后，此值域还有机会改变，那就不要为它提供设置函数。——这样你的意图会更加清晰，并且可以排除其值被修改的可能性。

Example：

 

 Hide Method

 

状况：如有有一个函数，从来没有被其他class用到，那么将这个函数设置为private。

 

动机：

　　1、重构往往促使你修改“函数的可见度“。——时刻检查可被隐藏的函数。

　　  2、经常检查有没有可能降低某个函数的可见度（使它私有化）。

　　　　——>当你在另一个class中移除对某个函数的调用时，就应该检查。

　　　　——>特别对setter函数进行上述的检查。

 

　　

 Replace Constructor with Factory Method

 

状况：如果你希望在创建对象时不仅仅是对它做简单的构件动作，那么将__construct（构造函数）替换为factory method。

动机：

　　在subclass过程中以factory method取代type code。——你可能常常需要type code创建相应的对象。

 Example：

            

            

接着来：

 

Replace Error Code with Exception

Situation: If a function returns a special code to indicate an error condition, then use Exception instead.

Motive:

Clearly separate "normal program" and "error handling", which makes the program easier to "understand".

Example:

conclusion

I would like to share my every harvest with you. If you gain even a little bit, it will make me very happy. If there are any mistakes in the article, please give me some pointers.

I don’t know if I’m looking in the wrong place. Some bloggers left a message saying “C# is mainly popular in the blog garden”. Does it mean that the people are mainly PHP programmers? There are still very few people leaving messages for me, and very few people pointing out the errors in my articles (are there really no errors in my articles?). Yesterday, "@四EYED Masked Man" left me a message. I learned a lot from talking with him, and I am grateful for his criticism and correction. I hope to communicate more with everyone.

http://www.bkjia.com/PHPjc/325485.htmlwww.bkjia.comtruehttp: //www.bkjia.com/PHPjc/325485.htmlTechArticleMind map introduces the previous series of articles. I am more concerned about the PHP talk "Refactoring-Improving the Existing One of Code Design" is to reorganize your functions, but I think I still haven't made it clear...