PHP でオブジェクト指向に関する 7 つの良い習慣を身につける

PHP でオブジェクト指向に関する 7 つの良い習慣を身につけよう

?

PHP プログラミングの初期の頃、PHP コードは本質的に手続き型に限定されていました。 手続き型コード は、手続きを使用してアプリケーション ブロックを構築することを特徴としています。プロシージャは、プロシージャ間の呼び出しを許可することにより、ある程度の再利用を提供します。

ただし、オブジェクト指向言語構造がなくても、プログラマは OO 機能を PHP コードに導入できます。これを行うのは少し難しく、混合パラダイム (擬似 OO 設計を備えた手続き型言語) であるため、コードが読みにくくなります。 PHP コードで OO 構成要素 (クラスを定義して使用する機能、継承を使用してクラス間の関係を構築する機能、インターフェイスを定義する機能など) を使用すると、優れた OO プラクティスに準拠したコードを簡単に構築できます。

過剰なモジュール性のない純粋に手続き型の設計はうまく機能しますが、OO 設計の利点はメンテナンスに現れます。一般的なアプリケーションのライフサイクルのほとんどはメンテナンスに費やされるため、コードのメンテナンスはアプリケーションのライフサイクルの重要な部分です。また、コードのメンテナンスは開発中に忘れられがちです。アプリケーションの開発と展開で競争が発生すると、長期的な保守性が後回しになる可能性があります。

モジュール性? (優れた OO 設計の主な機能の 1 つ) は、このようなメンテナンスに役立ちます。モジュール性は変更をカプセル化するのに役立ち、時間の経過とともにアプリケーションをより簡単に拡張および変更できるようになります。

要約すると、OO ソフトウェアを構築するには 7 つ以上の習慣がありますが、これらの 7 つの習慣に従うことで、コードが基本的な OO 設計標準に準拠した状態に保たれます。これらは、より多くの OO 習慣を構築し、簡単に保守および拡張できるソフトウェアを構築するための強力な基盤を提供します。これらの習慣は、モジュール性のいくつかの重要な機能を対象としています。言語に依存しない OO 設計の利点の詳細については、「リソース」を参照してください。

PHP OO の 7 つの優れた習慣は次のとおりです:

1. 謙虚さを保ちましょう。
2. 良き隣人になりましょう。
3. メデューサに会わないようにしてください。
4. 最も弱い部分を利用します。
5. あなたはゴムであり、私は接着剤です。
6. 拡散を制限します。
7. パターンの使用を検討してください。

謙虚でありなさい

控えめであるということは、クラスの実装や関数の実装において自分自身をさらけ出すことを避けることを意味します。自分の情報を隠すのは基本的な習慣です。実装の詳細を隠す習慣を身につけることができない場合、他の習慣を身につけるのは困難になります。情報の隠蔽はカプセル化とも呼ばれます。

パブリック フィールドを直接公開することは、さまざまな理由から悪い習慣です。その中で最も重要なのは、変更を実装する際の選択肢が少なくなるということです。変更は OO の概念を使用して分離され、カプセル化は変更がウイルス性の性質のものではないことを保証する上で重要な役割を果たします。 Viral? 最初は小さな変更です。3 つの要素を含む配列を 2 つの要素のみを含む配列に変更するなどです。突然、些細な変更であるはずのコードをさらに変更する必要があることがわかります。

情報の非表示を開始する簡単な方法は、フィールドを非公開にし、家の窓などのパブリック アクセス方法を使用して公開することです。壁全体を外に向かって開いたままにするのではなく、窓を 1 ～ 2 つだけ開けてください (アクセス方法については、「グッド プラクティス: パブリック アクセス方法の使用」で詳しく説明します)。

実装を変更の背後に隠すことができることに加えて、フィールドを直接公開する代わりにパブリック アクセス メソッドを使用すると、アクセス メソッドの実装をオーバーライドして、親メソッドの動作とはわずかに異なる動作を実行することで、基本実装を構築することができます。また、実際の実装が基本実装をオーバーライドするクラスに委任されるような抽象実装を構築することもできます。

悪い習慣: パブリックフィールドを公開する

リスト 1 の悪いコード例では、Person?オブジェクトのフィールドは、アクセス メソッドを使用するのではなく、パブリック フィールドとして直接公開されています。この動作は、特に軽量のデータ オブジェクトの場合には魅力的ですが、制限が課せられます。

リスト 1. パブリックフィールドを公開する悪い習慣

<?php
class Person
{
    public $prefix;
    public $givenName;
    public $familyName;
    public $suffix;
}

$person = new Person();
$person->prefix = "Mr.";
$person->givenName = "John";

echo($person->prefix);
echo($person->givenName);

?>

オブジェクトが何らかの形で変更された場合、そのオブジェクトを使用するすべてのコードも同様に変更する必要があります。たとえば、誰かの名、姓、その他の名前が ?PersonName? オブジェクトにカプセル化されている場合、変更に対応するためにすべてのコードを変更する必要があります。

グッドプラクティス: パブリックアクセスメソッドを使用する

優れた OO の習慣 (リスト 2 を参照) を使用することで、同じオブジェクトにパブリック フィールドの代わりにプライベート フィールドが設定され、 および ? というメソッドを介してアクセスできるようになります。外の世界。これらのアクセス メソッドは、PHP クラスから情報を取得するためのパブリックな方法を提供するため、実装が変更された場合でも、そのクラスを使用するすべてのコードを変更する必要が少なくなる可能性があります。 get set

チェックリスト 2. パブリック アクセス方法を使用するための良い習慣

乍看之下，这段代码可能会完成大量工作，并且实际上可能更多是在前端的工作。但是，通常，使用优秀的 OO 习惯从长远来看十分划算，因为将极大地巩固未来更改。

在清单 3 中所示的代码版本中，我已经更改了内部实现以使用名称部件的关联数组。比较理想的情况是，我希望拥有错误处理并且更仔细地检查元素是否存在，但是本例的目的在于展示使用我的类的代码无需更改的程度 ― 代码并没有察觉到类发生更改。记住采用 OO 习惯的原因是要谨慎封装更改，这样代码将更具有可扩展性并且更容易维护。

清单 3. 使用不同内部实现的另一个示例

<?php
class Person
{
    private $personName = array();
    
    public function setPrefix($prefix)
    {
        $this->personName['prefix'] = $prefix;
    }
    
    public function getPrefix()
    {
        return $this->personName['prefix'];
    }
    
    public function setGivenName($gn)
    {
        $this->personName['givenName'] = $gn;
    }
    
    public function getGivenName()
    {
        return $this->personName['givenName'];
    }

    /* etc... */
}

/*
 * Even though the internal implementation changed, the code here stays exactly
 * the same. The change has been encapsulated only to the Person class.
 */
$person = new Person();
$person->setPrefix("Mr.");
$person->setGivenName("John");

echo($person->getPrefix());
echo($person->getGivenName());

?>

?

做个好邻居

在构建类时，它应当正确地处理自己的错误。如果该类不知道如何处理错误，则应当以其调用者理解的格式封装这些错误。此外，避免返回空对象或者状态无效的对象。许多时候，只需通过检验参数并抛出特定异常说明提供参数无效的原因就可以实现这一点。在您养成这个习惯时，它可以帮您 ― 和维护代码或使用对象的人员 ― 节省很多时间。

坏习惯：不处理错误

考虑清单 4 中所示的示例，该示例将接受一些参数并返回填充了一些值的?Person?对象。但是，在?parsePersonName()?方法中，没有验证提供的?$val?变量是否为空、是否是零长度字符串或者字符串是否使用无法解析的格式。parsePersonName()?方法不返回Person?对象，但是返回 null。使用这种方法的管理员或程序员可能会觉得很麻烦 ― 至少他们现在需要开始设置断点并调试 PHP 脚本。

清单 4. 不抛出或处理错误的坏习惯

class PersonUtils
{
    public static function parsePersonName($format, $val)
    {
        if (strpos(",", $val) > 0) {
            $person = new Person();
            $parts = split(",", $val); // Assume the value is last, first
            $person->setGivenName($parts[1]);
            $person->setFamilyName($parts[0]);
        }
        return $person;
    }
}

清单 4 中的?parsePersonName()?方法可以修改为在?if?条件外部初始化?Person?对象，确保总是获得有效的?Person?对象。但是，您得到的是没有 set 属性的?Person，这仍然没有很好地改善您的困境。

好习惯：每个模块都处理自己的错误

不要让调用方凭空猜测，而是对参数进行预先验证。如果未设置的变量无法生成有效的结果，请检查变量并抛出InvalidArgumentException。如果字符串不能为空或者必须为特定格式，请检查格式并抛出异常。清单 5 解释了如何在演示一些基本验证的?parsePerson()?方法中创建异常以及一些新条件。

清单 5. 抛出错误的好习惯

<?php
class InvalidPersonNameFormatException extends LogicException {}


class PersonUtils
{
    public static function parsePersonName($format, $val)
    {
        if (! $format) {
            throw new InvalidPersonNameFormatException("Invalid PersonName format.");
        }

        if ((! isset($val)) || strlen($val) == 0) {
            throw new InvalidArgumentException("Must supply a non-null value to parse.");
        }


    }
}
?>

最终目的是希望人们能够使用您的类，而不必了解其中的工作原理。如果他们使用的方法不正确或者不是按照期望的方法使用，也不需要猜测不能工作的原因。作为一个好邻居，您需要知道对您的类进行重用的人并没有特异功能，因此您需要解决猜测的问题。

?

避免看到美杜莎

在我最初了解 OO 概念时，我十分怀疑接口是否真正有帮助。我的同事给我打了个比方，说不使用接口就好像看到美杜莎的头。在希腊神话中，美杜莎是长着蛇发的女怪。凡是看了她一眼的人都会变成石头。杀死美杜莎的珀尔休斯通过在盾上观察她的影子，避免了变成石头而得以与她对抗。

接口就是对付美杜莎的镜子。当您使用一个特定的具体实现时，代码也必须随着实现代码的更改而更改。直接使用实现将限制您的选择，因为您已经在本质上把类变成了 “石头”。

坏习惯：不使用接口

清单 6 显示了从数据库中装入?Person?对象的示例。它将获取人员的姓名并返回数据库中匹配的?Person?对象。

清单 6. 不使用接口的坏习惯

<?php
class DBPersonProvider
{
    public function getPerson($givenName, $familyName)
    {
        /* go to the database, get the person... */
        $person = new Person();
        $person->setPrefix("Mr.");
        $person->setGivenName("John");
        return $person;
    }
}

/* I need to get person data... */
$provider = new DBPersonProvider();
$person = $provider->getPerson("John", "Doe");

echo($person->getPrefix());
echo($person->getGivenName());

?>

在环境发生更改之前，从数据库中装入?Person?的代码都可以正常运行。例如，从数据库装入?Person?可能适用于第一个版本的应用程序，但是对于第二个版本，可能需要添加从 Web 服务装入人员的功能。其实，该类已经变成 “石头”，因为它在直接使用实现类并且现在能做的更改十分有限。

好习惯：使用接口

清单 7 显示了一个代码示例，在实现了加载用户的新方法后并没有进行更改。该示例显示了一个名为?PersonProvider?的接口，该接口将声明单个方法。如果任何代码使用?PersonProvider，代码都禁止直接使用实现类。相反，它就像是一个实际对象一样使用PersonProvider。

清单 7. 使用接口的好习惯

<?php
interface PersonProvider
{
    public function getPerson($givenName, $familyName);
}

class DBPersonProvider implements PersonProvider 
{
    public function getPerson($givenName, $familyName)
    {
        /* pretend to go to the database, get the person... */
        $person = new Person();
        $person->setPrefix("Mr.");
        $person->setGivenName("John");
        return $person;
    }
}

class PersonProviderFactory
{
    public static function createProvider($type)
    {
        if ($type == 'database')
        {
            return new DBPersonProvider();
        } else {
            return new NullProvider();
        }
    }
}

$config = 'database';
/* I need to get person data... */
$provider = PersonProviderFactory::createProvider($config);
$person = $provider->getPerson("John", "Doe");

echo($person->getPrefix());
echo($person->getGivenName());
?>

在使用接口时，尝试避免直接引用实现类。相反，使用对象外部的内容可以提供正确的实现。如果您的类将装入基于某些逻辑的实现，它仍然需要获取所有实现类的定义，并且那样做也无法取得任何效果。

您可以使用 Factory 模式来创建实现接口的实现类的实例。根据约定，factory?方法将以?create?为开头并返回接口。它可以为您的factory?获取必要的参数以计算出应当返回哪个实现类。

在清单 7 中，createProvider()?方法只是获取?$type。如果?$type?被设为?database，工厂将返回?DBPersonProvider?的实例。从数据库中装入人员的任何新实现都不要求在使用工厂和接口的类中进行任何更改。DBPersonProvider?将实现PersonProvider?接口并且拥有?getPerson()?方法的实际实现。

?

利用最弱的链接

将模块松散耦合?在一起是件好事情；它是允许您封装更改的属性之一。另外两个习惯 ― “保持谨慎” 和 “避免看到美杜莎” ― 可帮助您构建松散耦合的模块。要实现松散耦合的类，可通过养成降低类依赖关系的习惯实现。

坏习惯：紧密耦合

在清单 8 中，降低依赖关系并不是必须降低使用对象的客户机的依赖关系。相反，该示例将演示如何降低与正确类的依赖关系并最小化这种依赖关系。

清单 8.?Address?中紧密耦合的坏习惯

<?php

require_once "./AddressFormatters.php";

class Address
{
    private $addressLine1;
    private $addressLine2;
    private $city;
    private $state; // or province...
    private $postalCode;
    private $country;

    public function setAddressLine1($line1)
    {
        $this->addressLine1 = $line1;
    }

		/* accessors, etc... */

    public function getCountry()
    {
        return $this->country;
    }

    public function format($type)
    {
        if ($type == "inline") {
            $formatter = new InlineAddressFormatter();
        } else if ($type == "multiline") {
            $formatter = new MultilineAddressFormatter();
        } else {
            $formatter = new NullAddressFormatter();
        }
        return $formatter->format($this->getAddressLine1(), 
            $this->getAddressLine2(), 
            $this->getCity(), $this->getState(), $this->getPostalCode(), 
            $this->getCountry());
    }
}

$addr = new Address();
$addr->setAddressLine1("123 Any St.");
$addr->setAddressLine2("Ste 200");
$addr->setCity("Anytown");
$addr->setState("AY");
$addr->setPostalCode("55555-0000");
$addr->setCountry("US");

echo($addr->format("multiline"));
echo("\n");

echo($addr->format("inline"));
echo("\n");

?>

在?Address?对象上调用?format()?方法的代码可能看上去很棒 ― 这段代码所做的是使用?Address?类，调用?format()?并完成。相反，Address?类就没那么幸运。它需要了解用于正确格式化的各种格式化方法，这可能使?Address?对象无法被其他人很好地重用，尤其是在其他人没有兴趣在?format()?方法中使用格式化方法类的情况下。虽然使用?Address?的代码没有许多依赖关系，但是Address?类却有大量代码，而它可能只是一个简单的数据对象。

Address?类与知道如何格式化?Address?对象的实现类紧密耦合。

好习惯：在对象之间松散耦合

在构建优秀的 OO 设计时，必须考虑称为关注点分离（Separation of Concerns，SoC）的概念。SoC 指尝试通过真正关注的内容分离对象，从而降低耦合度。在最初的?Address?类中，它必须关注如何进行格式化。这可能不是优秀的设计。然而，Address?类应当考虑?Address?的各部分，而某种格式化方法应当关注如何正确格式化地址。

在清单 9 中，格式化地址的代码被移到接口、实现类和工厂中 ― 养成 “使用接口” 的习惯。现在，AddressFormatUtils?类负责创建格式化方法并格式化?Address。任何其他对象现在都可以使用?Address?而不必担心要求获得格式化方法的定义。

清单 9. 在对象之间松散耦合的好习惯

<?php

interface AddressFormatter
{
    public function format($addressLine1, $addressLine2, $city, $state, 
        $postalCode, $country);
}

class MultiLineAddressFormatter implements AddressFormatter 
{
    public function format($addressLine1, $addressLine2, $city, $state, 
        $postalCode, $country)
    {
        return sprintf("%s\n%s\n%s, %s %s\n%s", 
            $addressLine1, $addressLine2, $city, $state, $postalCode, $country);
    }
}

class InlineAddressFormatter implements AddressFormatter 
{
    public function format($addressLine1, $addressLine2, $city, $state, 
        $postalCode, $country)
    {
        return sprintf("%s %s, %s, %s %s %s", 
            $addressLine1, $addressLine2, $city, $state, $postalCode, $country);
    }
}

class AddressFormatUtils 
{
    public static function formatAddress($type, $address)
    {
        $formatter = AddressFormatUtils::createAddressFormatter($type);
        
        return $formatter->format($address->getAddressLine1(), 
            $address->getAddressLine2(), 
            $address->getCity(), $address->getState(), 
            $address->getPostalCode(), 
            $address->getCountry());
    }
    
    private static function createAddressFormatter($type)
    {
        if ($type == "inline") {
            $formatter = new InlineAddressFormatter();
        } else if ($type == "multiline") {
            $formatter = new MultilineAddressFormatter();
        } else {
            $formatter = new NullAddressFormatter();
        }
        return $formatter;
    }
}

$addr = new Address();
$addr->setAddressLine1("123 Any St.");
$addr->setAddressLine2("Ste 200");
$addr->setCity("Anytown");
$addr->setState("AY");
$addr->setPostalCode("55555-0000");
$addr->setCountry("US");

echo(AddressFormatUtils::formatAddress("multiline", $addr));
echo("\n");

echo(AddressFormatUtils::formatAddress("inline", $addr));
echo("\n");
?>

当然，缺点是只要使用模式，通常就意味着工件（类、文件）的数量会增加。但是，通过减少每个类中的维护可以弥补这个缺点，甚至在获得正确的可重用性时反而可以减少工件量。

您是橡皮；我是胶水

具有高度内聚力的 OO 设计被集中并组织到相关模块中。了解 “关注点” 对于决定如何紧密地联系函数和类十分重要。

坏习惯：降低内聚力

当设计的内聚力较低?时，它就不能良好地组织类和方法。意大利面条式代码（spaghetti code）一词通常用于描述捆绑在一起并且具有低内聚力的类和方法。清单 10 提供了意大利面条式代码的示例。相对通用的?Utils?类将使用许多不同对象并且有许多依赖关系。它执行很多操作，因而很难实现重用。

清单 10. 降低内聚力的坏习惯

<?php

class Utils
{
    public static function formatAddress($formatType, $address1, 
        $address2, $city, $state)
    {
        return "some address string";
    }
    
    public static function formatPersonName($formatType, $givenName, 
        $familyName)
    {
        return "some person name";
    }
    
    public static function parseAddress($formatType, $val)
    {
        // real implementation would set values, etc...
        return new Address();
    }
    
    public static function parseTelephoneNumber($formatType, $val)
    {
        // real implementation would set values, etc...
        return new TelephoneNumber();
    }
}

?>

好习惯：利用高内聚力

高内聚力?指将相互关联的类和方法分组在一起。如果方法和类都具有高度的内聚力，则可以轻松地分解整个组而不影响设计。具有高内聚力的设计将提供降低耦合的机会。清单 11 显示了被较好组织到类中的两个方法。AddressUtils?类将包含用于处理?Address类的方法，显示了与地址相关的方法之间的高度内聚力。同样地，PersonUtils?将包含专门处理?Person?对象的方法。这两个拥有高度内聚力方法的新类的耦合性都很低，因为可以完全独立地使用。

清单 11. 高内聚力的好习惯

<?php

class AddressUtils
{
    public static function formatAddress($formatType, $address1, 
        $address2, $city, $state)
    {
        return "some address string";
    }
    
    public static function parseAddress($formatType, $val)
    {
        // real implementation would set values, etc...
        return new Address();
    }
    
}

class PersonUtils
{
    public static function formatPersonName($formatType, $givenName, 
        $familyName)
    {
        return "some person name";
    }
    
    public static function parsePersonName($formatType, $val)
    {
        // real implementation would set values, etc...
        return new PersonName();
    }
}

?>

?

限制传播

我经常对我所在的软件团队（我在其中担任技术主管或架构师）的成员提起，OO 语言最大的敌人是复制和粘贴操作。当在缺少预先 OO 设计的情况下使用时，没有任何操作会像在类之间复制代码那样具有破坏性。无论何时，如果想将代码从一个类复制到下一个类中，请停下来并考虑如何使用类层次结构利用类似功能或相同功能。在大多数情况下，使用优秀设计后，您将会发现完全没有必要复制代码。

坏习惯：不使用类层次结构

清单 12 显示了部分类的简单示例。它们从重复的字段和方法开始 ― 从长远来看，不利于应用程序作出更改。如果?Person?类中有缺陷，则?Employee?类中也很可能有一个缺陷，因为看上去似乎实现是在两个类之间复制的。

清单 12. 不使用层次结构的坏习惯

<?php
class Person
{
    private $givenName;
    private $familyName;
}

class Employee
{
    private $givenName;
    private $familyName;
}

?>

继承?是一个很难入手的习惯，因为构建正确继承模型的分析通常需要花费大量时间。反过来，使用?Ctrl+C?组合键和?Ctrl+V?组合键构建新实现只需几秒钟。但是省下的这部分时间通常会在维护阶段迅速抵销掉，因为应用程序实际上将花费大量进行维护。

好习惯：利用继承

在清单 13 中，新?Employee?类将扩展?Person?类。它现在将继承所有通用方法并且不重新实现这些方法。此外，清单 13 显示了抽象方法的用法，演示如何将基本功能放入基类中以及如何阻止实现类使用特定函数。

清单 13. 利用继承的好习惯

<?php
abstract class Person
{
    private $givenName;
    private $familyName;
    
    public function setGivenName($gn)
    {
        $this->givenName = $gn;
    }
    
    public function getGivenName()
    {
        return $this->givenName;
    }
    
    public function setFamilyName($fn)
    {
        $this->familyName = $fn;
    }
    
    public function getFamilyName()
    {
        return $this->familyName;
    }
     
    public function sayHello()
    {
        echo("Hello, I am ");
        $this->introduceSelf();
    }
    
    abstract public function introduceSelf();
    
}

class Employee extends Person
{
    private $role;
    
    public function setRole($r)
    {
        $this->role = $r; 
    }
    
    public function getRole()
    {
        return $this->role;
    }
    
    public function introduceSelf()
    {
        echo($this->getRole() . " " . $this->getGivenName() . " " . 
            $this->getFamilyName());
    }
}
?>

?

パターンの使用を検討してください

デザイン パターンは、オブジェクトとメソッドの一般的な相互作用を指し、特定の問題を解決できることが時間の経過とともに証明されています。デザイン パターンの使用を考えるときは、クラスがどのように相互作用するかを理解する必要があります。これは、他の人の間違いを繰り返す必要がなく、実証済みの設計の恩恵を受けることなく、クラスとその相互作用を構築する簡単な方法です。

悪い習慣: 一度に 1 つのオブジェクトについて考える

パターンの使用について考える方法を示す適切なコード例は実際にはありません (ただし、パターンの実装を示す優れた例は豊富にあります)。ただし、一般に、次の場合には一度に 1 つのオブジェクトしか考慮できないことがわかります。

• オブジェクトモデルは事前に設計されません。
• モデルの大部分を削除せずに、単一のメソッドの実装を書き始めます。
• 会話ではデザイン パターン名を使用せず、実装について話すことを好みます。

グッドプラクティス: パターンで形成されたオブジェクトも追加します

一般に、次のことを行うときは使用パターンについて考えます。

• クラスとその相互作用を事前に作成します。
• パターンに基づいてクラスを適用します。
• ?Factory、Singleton、?Facade などのパターン名を使用します。
• モデルの大部分を削除し、実装の追加を開始します。

?

結論

PHP で OO の良い習慣を身につけると、より安定し、保守しやすく、拡張しやすいアプリケーションを構築するのに役立ちます。覚えておいてください:

• 引き続き注意してください。
• 良き隣人になりましょう。
• メデューサに会わないようにしてください。
• 最も弱い部分を利用します。
• あなたはゴムで、私は接着剤です。
• 拡散を制限します。
• パターンの使用を検討してください。

これらの習慣を身に付けて適用すると、アプリの品質の飛躍的な向上に驚かれることでしょう。