工厂模式
在大型系统中,许多代码依赖于少数几个关键类。需要更改这些类时,可能会出现困难。例如,假设您有一个从文件读取的 User
类。您希望将其更改为从数据库读取的其他类,但是,所有的代码都引用从文件读取的原始类。这时候,使用工厂模式会很方便。
工厂模式 是一种类,它具有为您创建对象的某些方法。您可以使用工厂类创建对象,而不直接使用 new
。这样,如果您想要更改所创建的对象类型,只需更改该工厂即可。使用该工厂的所有代码会自动更改。
清单 1 显示工厂类的一个示列。等式的服务器端包括两个部分:数据库和一组 PHP 页面,这些页面允许您添加反馈、请求反馈列表并获取与特定反馈相关的文章。
清单 1. Factory1.php
<?php
interface IUser
{function getName();
}class User implements IUser
{public function __construct( $id ) { }public function getName(){return "Jack";}
}class UserFactory
{public static function Create( $id ){return new User( $id );}
}$uo = UserFactory::Create( 1 );
echo( $uo->getName()."\n" );
?>
单元素模式(单列模式)
某些应用程序资源是独占的,因为有且只有一个此类型的资源。例如,通过数据库句柄到数据库的连接是独占的。您希望在应用程序中共享数据库句柄,因为在保持连接打开或关闭时,它是一种开销,在获取单个页面的过程中更是如此。
单元素模式可以满足此要求。如果应用程序每次包含且仅包含一个对象,那么这个对象就是一个单元素(Singleton)。清单 3 中的代码显示了 PHP V5 中的一个数据库连接单元素。
- php的应用主要在于数据库应用, 一个应用中会存在大量的数据库操作, 在使用面向对象的方式开发时, 如果使用单例模式, 则可以避免大量的new 操作消耗的资源,还可以减少数据库连接这样就不容易出现 too many connections情况。
- 如果系统中需要有一个类来全局控制某些配置信息, 那么使用单例模式可以很方便的实现. 这个可以参看zend Framework的FrontController部分。
- 在一次页面请求中, 便于进行调
清单 3. Singleton.php
<?php
require_once("DB.php");class DatabaseConnection
{public static function get(){static $db = null;if ( $db == null )$db = new DatabaseConnection();return $db;}private $_handle = null;private function __construct(){$dsn = 'mysql://root:password@localhost/photos';$this->_handle =& DB::Connect( $dsn, array() );}public function handle(){return $this->_handle;}
}print( "Handle = ".DatabaseConnection::get()->handle()."\n" );
print( "Handle = ".DatabaseConnection::get()->handle()."\n" );
?>
您可以使用全局变量存储数据库句柄,但是,该方法仅适用于较小的应用程序。在较大的应用程序中,应避免使用全局变量,并使用对象和方法访问资源。
观察者模式
观察者模式为您提供了避免组件之间紧密耦合的另一种方法。该模式非常简单:一个对象通过添加一个方法(该方法允许另一个对象,即观察者 注册自己)使本身变得可观察。当可观察的对象更改时,它会将消息发送到已注册的观察者。这些观察者使用该信息执行的操作与可观察的对象无关。结果是对象可以相互对话,而不必了解原因。
一个简单示例是系统中的用户列表。清单 4 中的代码显示一个用户列表,添加用户时,它将发送出一条消息。添加用户时,通过发送消息的日志观察者可以观察此列表。
清单 4. Observer.php
<?php
interface IObserver
{function onChanged( $sender, $args );
}interface IObservable
{function addObserver( $observer );
}class UserList implements IObservable
{private $_observers = array();public function addCustomer( $name ){foreach( $this->_observers as $obs )$obs->onChanged( $this, $name );}public function addObserver( $observer ){$this->_observers []= $observer;}
}class UserListLogger implements IObserver
{public function onChanged( $sender, $args ){echo( "'$args' added to user list\n" );}
}$ul = new UserList();
$ul->addObserver( new UserListLogger() );
$ul->add
此代码定义四个元素:两个接口和两个类。IObservable
接口定义可以被观察的对象,UserList
实现该接口,以便将本身注册为可观察。IObserver
列表定义要通过怎样的方法才能成为观察者,UserListLogger
实现 IObserver
接口。图 4 的 UML 中展示了这些元素。
图 4. 可观察的用户列表和用户列表事件日志程序
如果在命令行中运行它,您将看到以下输出:
% php observer.php 'Jack' added to user list %
测试代码创建 UserList
,并将 UserListLogger
观察者添加到其中。然后添加一个消费者,并将这一更改通知 UserListLogger
。
认识到 UserList
不知道日志程序将执行什么操作很关键。可能存在一个或多个执行其他操作的侦听程序。例如,您可能有一个向新用户发送消息的观察者,欢迎新用户使用该系统。这种方法的价值在于 UserList
忽略所有依赖它的对象,它主要关注在列表更改时维护用户列表并发送消息这一工作。
此模式不限于内存中的对象。它是在较大的应用程序中使用的数据库驱动的消息查询系统的基础。
策略模式
我们讲述的最后一个设计模式是策略 模式。在此模式中,算法是从复杂类提取的,因而可以方便地替换。例如,如果要更改搜索引擎中排列页的方法,则策略模式是一个不错的选择。思考一下搜索引擎的几个部分 —— 一部分遍历页面,一部分对每页排列,另一部分基于排列的结果排序。在复杂的示例中,这些部分都在同一个类中。通过使用策略模式,您可将排列部分放入另一个类中,以便更改页排列的方式,而不影响搜索引擎的其余代码。