PHP トーク「リファクタリング - 既存コードの設計の改善」パート 5 関数呼び出しの簡素化_PHP チュートリアル

思维导图


介绍

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

　　今天谈得是“接口”，此接口非“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：

            

            

接着来：

 

エラーコードを例外に置き換えます

状況: 関数がエラー状況を示す特別なコードを返す場合は、代わりに Exception を使用してください。

動機:

「通常のプログラム」と「エラー処理」を明確に分けることで、プログラムを「理解しやすく」します。

例:

結論

少しでも収穫があれば、皆さんとシェアさせていただきます。記事内に間違いがございましたら、ご指摘をお願いいたします。

探している場所が間違っているのかわかりませんが、「ブログ ガーデンでは主に C# が人気です」というメッセージを残している人もいました。もしかして、その人たちは主に PHP プログラマーなのでしょうか。未だにメッセージを残してくれる人が少なく、記事の間違いを指摘してくれる人も少ない（本当に記事に間違いがないのか？）昨日、「@四EYEDマスクマン」さんがメッセージを残してくれたことを知りました。彼と話してたくさんのことを学べたし、彼の批判や修正に感謝しているし、もっとみんなとコミュニケーションを図っていきたいと思っている。

http://www.bkjia.com/PHPjc/325485.htmlwww.bkjia.comtru​​ehttp://www.bkjia.com/PHPjc/325485.html技術記事マインドマップでは以前のシリーズ記事を紹介していますが、PHP チャットの 1 つである「リファクタリング - 既存のコードの設計の改善」で関数を再構成することのほうが気になりますが、まだ明確になっていないような気がします...