访问者模式

 

最近回去听beyond的歌，发现有几首被下架了，找遍了所有播放器，都没找到，然后网上查了一下原因，感觉，，怎么说呢，，我们来研究今天的设计模式吧。。。。。。

 

都说驴唇不对马嘴，我们来谈谈这个话题，我对马这个动物进行了封装，它有体重、年龄、性别、体力几个属性，有吃饭、负重奔跑、睡觉几个接口，这样封装足够目前的需求使用了，在后面的开发维护过程中我的需求里添加了卖马的功能，这个功能会用到马匹的年龄、性别、体力、体重等所有的属性，但是将此功能(sell)直接封装成类的成员函数貌似也不太合适，因为这个函数算法变化的机率很大，并且这个功能虽然用到了马的很多属性，但是此功能并不属于马的基础功能，好吧，咱们先把这个功能封装到马的类里，那么后面如果有需求要用马肉来做成驴肉火烧，需要用到马的体重来估算可以做成的火烧的个数，你说这个功能要不要封装到马类里面。

所以随着需求的不断变化递进，总有一些依赖类但不适合封装到类中的操作出现，在哪使用就在哪创建这个操作函数吗？也不好，可能这个功能操作需要在不同的应用场景里使用，随着这些操作的增多，我们就需要考虑如何去维护他们了。

进一步考虑，对象结构(存储维护着很多类的很多实例的结构类)在实际应用中也要考虑这个问题。我们有个班级的类，里面维护着N个普通学生、N个老师、1个班主任、2个班长。我们有很多操作需要访问这个对象结构，比如整个班级去献血，男生献血400ml，女生献血200ml；比如整个班级做学期评分，普通学生按照旷课和考试成绩评分，班长在此基础上有加分项，老师按照此学科及格、优秀率评分，班主任在此基础上有加分项；在比如班级植树活动，老师植树3棵，班长植树2棵，普通学生1棵树；这些功能明显会调用对象结构中每种对象的不同属性，但是这些功能并不适合封装在对象结构维护类中，但是随着这些类似的功能的增加，我们要考虑如何维护这些功能。

 

我们来总结一下，在上述应用场景里，有些功能需要访问目标（具体类、对象结构）的信息，但封装到具体目标中不仅会污染这些目标，还会随着功能的增到导致目标的臃肿不宜维护。我们可以对这些功能进行抽象封装，让他们去访问目标并完成自己的功能，同时也可以方便的扩展，针对这种场景，衍生