IObservable
接口定义可以被观察的对象,UserList
实现该接口,以便将本身注册为可观察。IObserver
列表定义要通过怎样的方法才能成为观察者,UserListLogger
实现 IObserver
接口。图 4 的 UML 中展示了这些元素。如果在命令行中运行它,您将看到以下输出:
% php observer.php |
测试代码创建 UserList
,并将 UserListLogger
观察者添加到其中。然后添加一个消费者,并将这一更改通知 UserListLogger
。
认识到 UserList
不知道日志程序将执行什么操作很关键。可能存在一个或多个执行其他操作的侦听程序。例如,您可能有一个向新用户发送消息的观察者,欢迎新用户使用该系统。这种方法的价值在于 UserList
忽略所有依赖它的对象,它主要关注在列表更改时维护用户列表并发送消息这一工作。
此模式不限于内存中的对象。它是在较大的应用程序中使用的数据库驱动的消息查询系统的基础。
命令链模式
命令链 模式以松散耦合主题为基础,发送消息、命令和请求,或通过一组处理程序发送任意内容。每个处理程序都会自行判断自己能否处理请求。如果可以,该请求被处理,进程停止。您可以为系统添加或移除处理程序,而不影响其他处理程序。清单 5 显示了此模式的一个示例。
<?php |
此代码定义维护 ICommand
对象列表的 CommandChain
类。两个类都可以实现 ICommand
接口 —— 一个对邮件的请求作出响应,另一个对添加用户作出响应。 图 5 给出了 UML。
如果您运行包含某些测试代码的脚本,则会得到以下输出:
% php chain.php |
代码首先创建 CommandChain
对象,并为它添加两个命令对象的实例。然后运行两个命令以查看谁对这些命令作出了响应。如果命令的名称匹配 UserCommand
或 MailCommand
,则代码失败,不发生任何操作。
为处理请求而创建可扩展的架构时,命令链模式很有价值,使用它可以解决许多问题。
策略模式
我们讲述的最后一个设计模式是策略 模式。在此模式中,算法是从复杂类提取的,因而可以方便地替换。例如,如果要更改搜索引擎中排列页的方法,则策略模式是一个不错的选择。思考一下搜索引擎的几个部分 —— 一部分遍历页面,一部分对每页排列,另一部分基于排列的结果排序。在复杂的示例中,这些部分都在同一个类中。通过使用策略模式,您可将排列部分放入另一个类中,以便更改页排列的方式,而不影响搜索引擎的其余代码。
作为一个较简单的示例,清单 6 显