在所有的设计模式中，访客模式可以算是比较难理解的一种设计模式。虽然这种模式很难理解，但是了解这种模式的工作原理也是很有必要的。我将从最简单的代码开始，并尝试解释这种模式的起源。先给出一个场景：顾客去商店购买商品，购物后需要到收银台结账。这里有几个关键词：customer（客户）、goods（商品）和cashier（出纳员），于是就有了如下代码：classCashier{publicfunctioncheckGoods(Goods$goods){echo"【Goods】Title:{$商品->标题}，价格：{$商品->价格}”；}}classGoods{public$title='';公共$价格=0；公共函数__construct($title,$price){$this->title=$title;$this->price=$price;}}/*客户端*/$pencil=newGoods('Pencil',2.5);$cashier=newCashier();$cashier->checkGoods($pencil);总体解释：顾客买了一支铅笔，顾客将铅笔交给收银员进行支票（checkGoods）。从宏观上看，收银员作为结账服务是没有问题的。毕竟，收银员是结账的。其实这有点类似于FacadePattern。那么有没有办法改变思维方式来设计呢？看下面的代码：}}classGoods{public$title='';公共$价格=0；公共函数__construct($title,$price){$this->title=$title;$this->price=$price;}publicfunctioncheckSelf(Cashier$cashier){$cashier->checkGoods($this);}}$pencil=newGoods('Pencil',2.5);$cashier=newCashier();$pencil->checkSelf($cashier);上面的代码在Goods中添加了一个checkSelf方法，用于接收Cashier实例。在checkSelf的这个方法中，我们调用实例的checkGoods方法。重写客户端的代码，不再使用checkGoods方法检查，而是使用checkSelf方法将cashier传入Goods。对比上面两段代码的区别，体验思路，这就是访客模式的雏形。下一步是抽象。对实例进行抽象，该用接口就用接口，该用继承就用继承。以下是对上述示例的重写"【商品】标题：{$element->title}，价格：{$element->price}";}}类Goods实现IElement{public$title='';公共$价格=0；公共函数__construct($title,$price){$this->title=$title;$this->price=$price;}publicfunctionaccept(IVisitor$visitor){$visitor->visit($this);}}$pencil=newGoods('铅笔',2.5);$收银员=新收银员();$pencil->accept($cashier);这样是不是好像明白了很多？其实设计模式并没有那么复杂，多半是思维方式的改变。
