段,并且通过称为访问方法 的 get 和 set 公共方法 谨慎地向外界公开私有字段。这些访问方法现在提供了一种从 PHP 类中获取信 息的公共方法,这样在实现发生更改时,更改使用类的所有代码的需求很可能变 小。
清单 2. 使用公共访问方法的好习惯
<?php
class Person
{
private $prefix;
private $givenName;
private $familyName;
private $suffix;
public function setPrefix($prefix)
{
$this->prefix = $prefix;
}
public function getPrefix()
{
return $this- >prefix;
}
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 setSuffix($suffix)
{
$this- >suffix = $suffix;
}
public function getSuffix()
{
return $suffix;
}
}
$person = new Person();
$person->setPrefix ("Mr.");
$person->setGivenName("John");
echo($person->getPrefix());
echo($person->getGivenName ());
?>
乍看之下,这段代码可能会完成大量工作,并 且实际上可能更多是在前端的工作。但是,通常,使用优秀的 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() 方法中,没有验 |