核心要點

• 空對象模式是一種設計模式，利用多態(tài)性減少條件代碼，使代碼更簡潔易維護。它提供一個非功能性對象，可以替代真實對象，從而無需進行空值檢查。
• 空對象模式可以與其他設計模式結合使用，例如工廠模式創(chuàng)建和返回空對象，或策略模式在運行時更改對象的行為。
• 空對象模式的潛在缺點是可能導致創(chuàng)建不必要的對象，增加內(nèi)存使用。它也可能使代碼更復雜，因為需要創(chuàng)建額外的類和接口。
• 實現(xiàn)空對象模式需要創(chuàng)建一個空對象類，該類實現(xiàn)與真實對象相同的接口。這個空對象為接口中的所有方法提供默認實現(xiàn)，允許它替代真實對象。這使得代碼更健壯，更不容易出錯。

雖然并非完全符合規(guī)范，但可以說正交性是基于“良好設計”原則的軟件系統(tǒng)的精髓，其中各個模塊彼此解耦，使系統(tǒng)不易出現(xiàn)僵化和脆弱的問題。當然，談論正交系統(tǒng)的優(yōu)點比實際運行生產(chǎn)系統(tǒng)更容易；這個過程通常是追求烏托邦。即使如此，在系統(tǒng)中實現(xiàn)高度解耦的組件絕非烏托邦的概念。多態(tài)性等多種編程概念允許設計靈活的程序，其各個部分可以在運行時切換，其依賴關系可以以抽象的形式表達，而不是具體的實現(xiàn)。我想說，無論我們是在實現(xiàn)基礎設施還是應用程序邏輯，“面向接口編程”的舊格言隨著時間的推移已經(jīng)得到了普遍的采用。然而，當踏上領域模型的領域時，情況就大相徑庭了。坦率地說，這是一個可預測的場景。畢竟，為什么一個相互關聯(lián)的對象網(wǎng)絡（其數(shù)據(jù)和行為受限于明確定義的業(yè)務規(guī)則）應該是多態(tài)的呢？它本身并沒有多大意義。不過，此規(guī)則有一些例外，最終可能適用于這種情況。第一個例外是使用虛擬代理，它有效地與實際領域對象實現(xiàn)的接口相同。另一個例外是所謂的“空情況”，這是一種特殊情況，其中操作最終可能分配或返回空值，而不是填充良好的實體。在傳統(tǒng)的非多態(tài)方法中，模型的使用者必須檢查這些“有害的”空值并優(yōu)雅地處理該條件，從而在整個代碼中產(chǎn)生條件語句的爆炸。幸運的是，只需創(chuàng)建領域對象的多分支實現(xiàn)即可輕松解決這種看似混亂的情況，該實現(xiàn)將實現(xiàn)與所討論對象相同的接口，只是其方法不會執(zhí)行任何操作，因此將客戶端代碼從在執(zhí)行操作時重復檢查難看的空值中解脫出來。毫不奇怪，這種方法是一種稱為空對象的設計模式，它將多態(tài)性的優(yōu)勢發(fā)揮到極致。在本文中，我將演示該模式在幾種情況下的好處，并向您展示它們?nèi)绾尉o密地依附于多態(tài)方法。

處理非多態(tài)條件

正如人們所料，在展示空對象模式的優(yōu)點時，有幾種方法可以嘗試。我發(fā)現(xiàn)一種特別直接的方法是實現(xiàn)一個數(shù)據(jù)映射器，它最終可能從通用查找器返回空值。假設我們已經(jīng)成功創(chuàng)建了一個骨架領域模型，該模型僅由一個用戶實體組成。接口及其類如下所示：

<?php namespace Model;

interface UserInterface
{
    public function setId($id);
    public function getId();

    public function setName($name);
    public function getName();

    public function setEmail($email);
    public function getEmail();
}

<?php namespace Model;

class User implements UserInterface
{
    private $id;
    private $name;
    private $email;

    public function __construct($name, $email) {
        $this->setName($name);
        $this->setEmail($email);
    }

    public function setId($id) {
        if ($this->id !== null) {
            throw new BadMethodCallException(
                "The ID for this user has been set already.");
        }
        if (!is_int($id) || $id             throw new InvalidArgumentException(
              "The ID for this user is invalid.");
        }
        $this->id = $id;
        return $this;
    }

    public function getId() {
        return $this->id;
    }

    public function setName($name) {
        if (strlen($name)  30) {
            throw new InvalidArgumentException(
                "The user name is invalid.");
        }
        $this->name = $name;
        return $this;
    }

    public function getName() {
        return $this->name;
    }

    public function setEmail($email) {
        if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
            throw new InvalidArgumentException(
                "The user email is invalid.");
        }
        $this->email = $email;
        return $this;
    }

    public function getEmail() {
        return $this->email;
    }
}

User 類是一個反應式結構，它實現(xiàn)了一些 mutators/accessors 來定義一些用戶的數(shù)據(jù)和行為。有了這個構造的領域類，我們現(xiàn)在可以更進一步，定義一個基本的數(shù)據(jù)映射器，它將我們的領域模型和數(shù)據(jù)訪問層彼此隔離。

<?php namespace ModelMapper;
use LibraryDatabaseDatabaseAdapterInterface,
    ModelUser;

class UserMapper implements UserMapperInterface
{   
    private $adapter;

    public function __construct(DatabaseAdapterInterface $adapter) {
        $this->adapter = $adapter;
    }

    public function fetchById($id) {
        $this->adapter->select("users", array("id" => $id));
        if (!$row = $this->adapter->fetch()) {
            return null;
        }
        return $this->createUser($row);
    }

    private function createUser(array $row) {
        $user = new User($row["name"], $row["email"]);
        $user->setId($row["id"]);
        return $user;
    }
}

首先應該出現(xiàn)的是映射器的 fetchById() 方法是塊中的淘氣鬼，因為它在數(shù)據(jù)庫中沒有用戶與給定的 ID 匹配時有效地返回 null。出于顯而易見的原因，這個笨拙的條件使得客戶端代碼每次調(diào)用映射器的查找器時都必須費力地檢查空值。

<?php use LibraryLoaderAutoloader,
    LibraryDatabasePdoAdapter,
    ModelMapperUserMapper;

require_once __DIR__ . "/Library/Loader/Autoloader.php";
$autoloader = new Autoloader;
$autoloader->register();

$adapter = new PdoAdapter("mysql:dbname=test", "myusername", "mypassword");

$userMapper = new UserMapper($adapter);

$user = $userMapper->fetchById(1);

if ($user !== null) {
    echo $user->getName() . " " . $user->getEmail();
}

乍一看，這不會有什么問題，只要在一個地方進行檢查即可。但是，如果相同的行出現(xiàn)在多個頁面控制器或服務層中，您會不會撞到磚墻上？在你意識到之前，映射器返回的看似無辜的 null 會產(chǎn)生大量重復的條件，這是設計不良的兇兆。

從客戶端代碼中刪除條件語句

然而，無需焦慮，因為這正是空對象模式顯示多態(tài)性為何是天賜之物的情況。如果我們想一勞永逸地擺脫那些討厭的條件語句，我們可以實現(xiàn)前面 User 類的多態(tài)版本。

<?php namespace Model;

class NullUser implements UserInterface
{
    public function setId($id) { }
    public function getId() { }

    public function setName($name) { }
    public function getName() { }

    public function setEmail($email) { }
    public function getEmail() { }
}

如果您期望一個完整的實體類打包各種各樣的裝飾，那么恐怕您會非常失望。“null”版本的實體符合相應的接口，但方法是空包裝器，沒有實際的實現(xiàn)。雖然 NullUser 類的存在顯然沒有給我們帶來任何值得稱贊的有用東西，但它是一個簡潔的結構，允許我們將所有之前的條件語句扔進垃圾桶。想看看它是如何實現(xiàn)的嗎？首先，我們應該做一些前期工作并重構數(shù)據(jù)映射器，以便它的查找器返回一個空用戶對象而不是空值。

<?php namespace ModelMapper;
use LibraryDatabaseDatabaseAdapterInterface,
    ModelUser,
    ModelNullUser;

class UserMapper implements UserMapperInterface
{   
    private $adapter;

    public function __construct(DatabaseAdapterInterface $adapter) {
        $this->adapter = $adapter;
    }

    public function fetchById($id) {
        $this->adapter->select("users", array("id" => $id));
        return $this->createUser($this->adapter->fetch());
    }

    private function createUser($row) {
        if (!$row) {
            return new NullUser;
        }
        $user = new User($row["name"], $row["email"]);
        $user->setId($row["id"]);
        return $user; 
    }
}

映射器的 createUser() 方法隱藏了一個微小的條件，因為它現(xiàn)在負責在傳遞給查找器的 ID 沒有返回有效用戶時創(chuàng)建一個空用戶。即便如此，這種細微的代價不僅可以節(jié)省客戶端代碼進行大量重復檢查的工作，而且還可以將其變成一個寬松的使用者，當它必須處理空用戶時不會抱怨。

<?php namespace Model;

interface UserInterface
{
    public function setId($id);
    public function getId();

    public function setName($name);
    public function getName();

    public function setEmail($email);
    public function getEmail();
}

這種多態(tài)方法的主要缺點是，任何使用它的應用程序都將變得過于寬松，因為它在處理無效實體時永遠不會崩潰。在最壞的情況下，用戶界面只會顯示一些空白行，但沒有任何真正嘈雜的東西讓我們感到厭惡。當掃描早期 NullUser 類的當前實現(xiàn)時，這一點尤其明顯。即使是可行的，更不用說推薦的了，在保持其多態(tài)性不變的同時，也可以在空對象中封裝邏輯。我什至可以說，空對象非常適合封裝默認數(shù)據(jù)和行為，這些數(shù)據(jù)和行為應該只在少數(shù)特殊情況下向客戶端代碼公開。如果您足夠雄心勃勃并且想使用簡單的空用戶對象嘗試這個概念，那么當前的 NullUser 類可以按以下方式重構：

<?php namespace Model;

class User implements UserInterface
{
    private $id;
    private $name;
    private $email;

    public function __construct($name, $email) {
        $this->setName($name);
        $this->setEmail($email);
    }

    public function setId($id) {
        if ($this->id !== null) {
            throw new BadMethodCallException(
                "The ID for this user has been set already.");
        }
        if (!is_int($id) || $id             throw new InvalidArgumentException(
              "The ID for this user is invalid.");
        }
        $this->id = $id;
        return $this;
    }

    public function getId() {
        return $this->id;
    }

    public function setName($name) {
        if (strlen($name)  30) {
            throw new InvalidArgumentException(
                "The user name is invalid.");
        }
        $this->name = $name;
        return $this;
    }

    public function getName() {
        return $this->name;
    }

    public function setEmail($email) {
        if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
            throw new InvalidArgumentException(
                "The user email is invalid.");
        }
        $this->email = $email;
        return $this;
    }

    public function getEmail() {
        return $this->email;
    }
}

增強的 NullUser 版本比其安靜的前身略微更具表達性，因為它的 getter 提供了一些基本的實現(xiàn)，以便在請求無效用戶時返回一些默認消息。雖然微不足道，但這項更改對客戶端代碼處理空用戶的方式產(chǎn)生了積極的影響，因為這次使用者至少清楚地知道當他們試圖從存儲中提取不存在的用戶時出現(xiàn)了一些問題。這是一個不錯的突破，它不僅展示了如何實現(xiàn)實際上根本不是空的空對象，還展示了根據(jù)特定需求在相關對象內(nèi)部移動邏輯是多么容易。

結束語

有些人可能會說，實現(xiàn)空對象很麻煩，尤其是在 PHP 中，OOP 的核心概念（如多態(tài)性）被明顯低估了。他們在某種程度上是對的。盡管如此，逐步采用值得信賴的編程原則和設計模式，以及該語言對象模型目前達到的成熟度水平，為穩(wěn)步前進和開始使用一些不久前被認為是復雜、不切實際的概念的“奢侈品”提供了所有必要的基礎?？諏ο竽Ｊ綄儆诖祟悇e，但其實現(xiàn)非常簡單和優(yōu)雅，以至于在清除客戶端代碼中的重復空值檢查時很難不覺得它很吸引人。 圖片來自 Fotolia

(由于篇幅限制，此處省略了原文中的FAQ部分。)

以上是PHP主|零對象模式 - 域模型中的多態(tài)性的詳細內(nèi)容。更多信息請關注PHP中文網(wǎng)其他相關文章！