在所有设计模式中，访问者模式算得上比较难理解的一种设计模式。虽然这种模式比较难理解，但是也需要去知道这种模式具体是怎么回事儿，我将从最简单的代码讲起，尝试去说说这种模式的由来。
先给定一个场景：顾客去商店买物品，购物结束后需要在收银员进行结账。
这里具体罗列一下几个关键词：顾客(client)、物品(goods)和收银员(cashier)
于是就有以下代码：
class Cashier { public function checkGoods(Goods $goods) { echo "【Goods】Title: {$goods->title}, price: {$goods->price}"; }}class Goods { public $title = ''; public $price = 0; public function __construct($title, $price) { $this->title = $title; $this->price = $price; }}/* client */$pencil = new Goods('铅笔', 2.5);$cashier = new Cashier();$cashier->checkGoods($pencil);总体解释：
- 顾客购买一支铅笔
- 顾客将铅笔交给收银员结账(checkGoods)
以上没问题，很多类似的项目也是这样设计的。宏观来说 cashier 作为服务去结账是没有问题的，毕竟收银员就是给客户结账的，其实这里有点类似外观模式(Facade Pattern)。
那么有没有办法换一种思路去设计呢？看下面的代码：
class Cashier { public function checkGoods(Goods $goods) { echo "【Goods】Title: {$goods->title}, price: {$goods->price}"; }}class Goods { public $title = ''; public $price = 0; public function __construct($title, $price) { $this->title = $title; $this->price = $price; } public function checkSelf(Cashier $cashier) { $cashier->checkGoods($this); }}$pencil = new Goods('铅笔', 2.5);$cashier = new Cashier();$pencil->checkSelf($cashier);以上代码在 Goods 中加了一个 checkSelf 方法用于接收 Cashier 实例，在 checkSelf 的这个方法中，我们调用了实例的 checkGoods 方法。改写 client 端的代码，将不在使用 checkGoods 方法进行检查，而使用的是 checkSelf 方法将 cashier 传入 Goods 中。
比较以上两段代码的区别，体会思维方式，这就是访问者模式的雏形。
接下来就是抽象了。把实例抽象化，该用接口的用接口，该用继承的用继承。
以下就是改写上面的例子
interface IVisitor { public function visit(IElement $element);}interface IElement { public function accept(IVisitor $visitor);}class Cashier implements IVisitor { public function visit(IElement $element) { echo "【Goods】Title: {$element->title}, price: {$element->price}"; }}class Goods implements IElement { public $title = ''; public $price = 0; public function __construct($title, $price) { $this->title = $title; $this->price = $price; } public function accept(IVisitor $visitor) { $visitor->visit($this); }}$pencil = new Goods('铅笔', 2.5);$cashier = new Cashier();$pencil->accept($cashier);这样看起来是不是能够理解不少呢？
其实设计模式没那么复杂，大部分是一种思维方式的转变。