程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> 網頁編程 >> PHP編程 >> PHP綜合 >> 深入講解PHP的Yii框架中的屬性(Property)

深入講解PHP的Yii框架中的屬性(Property)

編輯:PHP綜合

在 PHP 中,類的成員變量也被稱為屬性(properties)。它們是類定義的一部分,用來表現一個實例的狀態(也就是區分類的不同實例)。在具體實踐中,常常會想用一個稍微特殊些的方法實現屬性的讀寫。例如,如果有需求每次都要對 label 屬性執行 trim 操作,就可以用以下代碼實現:

$object->label = trim($label);

上述代碼的缺點是只要修改 label 屬性就必須再次調用 trim() 函數。若將來需要用其它方式處理 label 屬性,比如首字母大寫,就不得不修改所有給 label 屬性賦值的代碼。這種代碼的重復會導致 bug,這種實踐顯然需要盡可能避免。

為解決該問題,Yii 引入了一個名為 yii\base\Object 的基類,它支持基於類內的 getter 和 setter(讀取器和設定器)方法來定義屬性。如果某類需要支持這個特性,只需要繼承 yii\base\Object 或其子類即可。

補充:幾乎每個 Yii 框架的核心類都繼承自 yii\base\Object 或其子類。這意味著只要在核心類中見到 getter 或 setter 方法,就可以像調用屬性一樣調用它。
getter 方法是名稱以 get 開頭的方法,而 setter 方法名以 set 開頭。方法名中 get 或 set 後面的部分就定義了該屬性的名字。如下面代碼所示,getter 方法 getLabel() 和 setter 方法 setLabel() 操作的是 label 屬性,:

namespace app\components;

use yii\base\Object;

class Foo extend Object
{
  private $_label;

  public function getLabel()
  {
    return $this->_label;
  }

  public function setLabel($value)
  {
    $this->_label = trim($value);
  }
}

(詳細解釋:getter 和 setter 方法創建了一個名為 label 的屬性,在這個例子裡,它指向一個私有的內部屬性 _label。)

getter/setter 定義的屬性用法與類成員變量一樣。兩者主要的區別是:當這種屬性被讀取時,對應的 getter 方法將被調用;而當屬性被賦值時,對應的 setter 方法就調用。如:

// 等效於 $label = $object->getLabel();
$label = $object->label;

// 等效於 $object->setLabel('abc');
$object->label = 'abc';

只定義了 getter 沒有 setter 的屬性是只讀屬性。嘗試賦值給這樣的屬性將導致 yii\base\InvalidCallException (無效調用)異常。類似的,只有 setter 方法而沒有 getter 方法定義的屬性是只寫屬性,嘗試讀取這種屬性也會觸發異常。使用只寫屬性的情況幾乎沒有。

通過 getter 和 setter 定義的屬性也有一些特殊規則和限制:

這類屬性的名字是不區分大小寫的。如,$object->label 和 $object->Label 是同一個屬性。因為 PHP 方法名是不區分大小寫的。
如果此類屬性名和類成員變量相同,以後者為准。例如,假設以上 Foo 類有個 label 成員變量,然後給 $object->label = 'abc' 賦值,將賦給成員變量而不是 setter setLabel() 方法。
這類屬性不支持可見性(訪問限制)。定義屬性的 getter 和 setter 方法是 public、protected 還是 private 對屬性的可見性沒有任何影響。
這類屬性的 getter 和 setter 方法只能定義為非靜態的,若定義為靜態方法(static)則不會以相同方式處理。
回到開頭提到的問題,與其處處要調用 trim() 函數,現在我們只需在 setter setLabel() 方法內調用一次。如果 label 首字母變成大寫的新要求來了,我們只需要修改setLabel() 方法,而無須接觸任何其它代碼。

實現屬性的步驟

我們知道,在讀取和寫入對象的一個不存在的成員變量時, __get() __set() 會被自動調用。 Yii正是利用這點,提供對屬性的支持的。從上面的代碼中,可以看出,如果訪問一個對象的某個屬性, Yii會調用名為 get屬性名() 的函數。如, SomeObject->Foo , 會自動調用 SomeObject->getFoo() 。如果修改某一屬性,會調用相應的setter函數。 如, SomeObject->Foo = $someValue ,會自動調用 SomeObject->setFoo($someValue) 。

因此,要實現屬性,通常有三個步驟:

  • 繼承自 yii\base\Object 。
  • 聲明一個用於保存該屬性的私有成員變量。
  • 提供getter或setter函數,或兩者都提供,用於訪問、修改上面提到的私有成員變量。 如果只提供了getter,那麼該屬性為只讀屬性,只提供了setter,則為只寫。

如下的Post類,實現了可讀可寫的屬性title:

class Post extends yii\base\Object  // 第一步:繼承自 yii\base\Object
{
  private $_title;         // 第二步:聲明一個私有成員變量

  public function getTitle()    // 第三步:提供getter和setter
  {
    return $this->_title;
  }

  public function setTitle($value)
  {
    $this->_title = trim($value);
  }
}

從理論上來講,將 private $_title 寫成 public $title ,也是可以實現對 $post->title 的讀寫的。但這不是好的習慣,理由如下:

失去了類的封裝性。 一般而言,成員變量對外不可見是比較好的編程習慣。 從這裡你也許沒看出來,但是假如有一天,你不想讓用戶修改標題了,你怎麼改? 怎麼確保代碼中沒有直接修改標題? 如果提供了setter,只要把setter刪掉,那麼一旦有沒清理干淨的對標題的寫入,就會拋出異常。 而使用 public $title 的方法的話,你改成 private $title 可以排查寫入的異常,但是讀取的也被禁止了。
對於標題的寫入,你想去掉空格。 使用setter的方法,只需要像上面的代碼段一樣在這個地方調用 trim() 就可以了。 但如果使用 public $title 的方法,那麼毫無疑問,每個寫入語句都要調用 trim() 。 你能保證沒有一處遺漏?
因此,使用 public $title 只是一時之快,看起來簡單,但今後的修改是個麻煩事。 簡直可以說是惡夢。這就是軟件工程的意義所在,通過一定的方法,使代碼易於維護、便於修改。 一時看著好像沒必要,但實際上吃過虧的朋友或者被客戶老板逼著修改上一個程序員寫的代碼,問候過他親人的, 都會覺得這是十分必要的。

但是,世事無絕對。由於 __get() 和 __set() 是在遍歷所有成員變量,找不到匹配的成員變量時才被調用。 因此,其效率天生地低於使用成員變量的形式。在一些表示數據結構、數據集合等簡單情況下,且不需讀寫控制等, 可以考慮使用成員變量作為屬性,這樣可以提高一點效率。

另外一個提高效率的小技巧就是:使用 $pro = $object->getPro() 來代替 $pro = $object->pro , 用 $objcect->setPro($value) 來代替 $object->pro = $value 。 這在功能上是完全一樣的效果,但是避免了使用 __get() 和 __set() ,相當於繞過了遍歷的過程。

這裡估計有人該罵我了,Yii好不容易實現了屬性的機制,就是為了方便開發者, 結果我卻在這裡教大家怎麼使用原始的方式,去提高所謂的效率。 嗯,確實,開發的便利性與執行高效率存在一定的矛盾。我個人的觀點更傾向於以便利為先, 用好、用足Yii為我們創造的便利條件。至於效率的事情,更多的是框架自身需要注意的, 我們只要別寫出格外2的代碼就OK了。

不過你完全可以放心,在Yii的框架中,極少出現 $app->request 之類的代碼,而是使用 $app->getRequest() 。 換句話說,框架自身還是格外地注重效率的,至於便利性,則留給了開發者。 總之,這裡只是點出來有這麼一個知識點,至於用不用,怎麼用,完全取決於你了。

值得注意的是:

由於自動調用 __get() __set() 的時機僅僅發生在訪問不存在的成員變量時。 因此,如果定義了成員變量 public $title 那麼,就算定義了 getTitle() setTitle() , 他們也不會被調用。因為 $post->title 時,會直接指向該 pulic $title , __get() __set() 是不會被調用的。從根上就被切斷了。
由於PHP對於類方法不區分大小寫,即大小寫不敏感, $post->getTitle() 和 $post->gettitle() 是調用相同的函數。 因此, $post->title 和 $post->Title 是同一個屬性。即屬性名也是不區分大小寫的。
由於 __get() __set() 都是public的, 無論將 getTitle() setTitle() 聲明為 public, private, protected, 都沒有意義,外部同樣都是可以訪問。所以,所有的屬性都是public的。
由於 __get() __set() 都不是static的,因此,沒有辦法使用static 的屬性。
Object的其他與屬性相關的方法

除了 __get() __set() 之外, yii\base\Object 還提供了以下方法便於使用屬性:

  • __isset() 用於測試屬性值是否不為 null ,在 isset($object->property) 時被自動調用。 注意該屬性要有相應的getter。
  • __unset() 用於將屬性值設為 null ,在 unset($object->property) 時被自動調用。 注意該屬性要有相應的setter。
  • hasProperty() 用於測試是否有某個屬性。即,定義了getter或setter。 如果 hasProperty() 的參數 $checkVars = true (默認為true), 那麼只要具有同名的成員變量也認為具有該屬性,如前面提到的 public $title 。
  • canGetProperty() 測試一個屬性是否可讀,參數 $checkVars 的意義同上。只要定義了getter,屬性即可讀。 同時,如果 $checkVars 為 true 。那麼只要類定義了成員變量,不管是public, private 還是 protected, 都認為是可讀。
  • canSetProperty() 測試一個屬性是否可寫,參數 $checkVars 的意義同上。只要定義了setter,屬性即可寫。 同時,在 $checkVars 為 ture 。那麼只要類定義了成員變量,不管是public, private 還是 protected, 都認為是可寫。
  • Object和Component

yii\base\Component 繼承自 yii\base\Object ,因此,他也具有屬性等基本功能。

但是,由於Componet還引入了事件、行為,因此,它並非簡單繼承了Object的屬性實現方式,而是基於同樣的機制, 重載了 __get() __set() 等函數。但從實現機制上來講,是一樣的。這個不影響理解。

前面說過,官方將Yii定位於一個基於組件的框架。可見組件這一概念是Yii的基礎。 如果你有興趣閱讀Yii的源代碼或是API文檔,你將會發現, Yii幾乎所有的核心類都派生於(繼承自) yii\base\Component 。

在Yii1.1時,就已經有了component了,那時是 CComponent。Yii2將Yii1.1中的CComponent拆分成兩個類: yii\base\Object 和 yii\base\Component 。

其中,Object比較輕量級些,通過getter和setter定義了類的屬性(property)。 Component派生自Object,並支持事件(event)和行為(behavior)。因此,Component類具有三個重要的特性:

  • 屬性(property)
  • 事件(event)
  • 行為(behavior)

相信你或多或少了解過,這三個特性是豐富和拓展類功能、改變類行為的重要切入點。 因此,Component在Yii中的地位極高。

在提供更多功能、更多便利的同時,Component由於增加了event和behavior這兩個特性, 在方便開發的同時,也犧牲了一定的效率。 如果開發中不需要使用event和behavior這兩個特性,比如表示一些數據的類。 那麼,可以不從Component繼承,而從Object繼承。 典型的應用場景就是如果表示用戶輸入的一組數據,那麼,使用Object。 而如果需要對對象的行為和能響應處理的事件進行處理,毫無疑問應當采用Component。 從效率來講,Object更接近原生的PHP類,因此,在可能的情況下,應當優先使用Object。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved