最近回去听beyond的歌,发现有几首被下架了,找遍了所有播放器,都没找到,然后网上查了一下原因,感觉,,怎么说呢,,我们来研究今天的设计模式吧。。。。。。
都说驴唇不对马嘴,我们来谈谈这个话题,我对马这个动物进行了封装,它有体重、年龄、性别、体力几个属性,有吃饭、负重奔跑、睡觉几个接口,这样封装足够目前的需求使用了,在后面的开发维护过程中我的需求里添加了卖马的功能,这个功能会用到马匹的年龄、性别、体力、体重等所有的属性,但是将此功能(sell)直接封装成类的成员函数貌似也不太合适,因为这个函数算法变化的机率很大,并且这个功能虽然用到了马的很多属性,但是此功能并不属于马的基础功能,好吧,咱们先把这个功能封装到马的类里,那么后面如果有需求要用马肉来做成驴肉火烧,需要用到马的体重来估算可以做成的火烧的个数,你说这个功能要不要封装到马类里面。
所以随着需求的不断变化递进,总有一些依赖类但不适合封装到类中的操作出现,在哪使用就在哪创建这个操作函数吗?也不好,可能这个功能操作需要在不同的应用场景里使用,随着这些操作的增多,我们就需要考虑如何去维护他们了。
进一步考虑,对象结构(存储维护着很多类的很多实例的结构类)在实际应用中也要考虑这个问题。我们有个班级的类,里面维护着N个普通学生、N个老师、1个班主任、2个班长。我们有很多操作需要访问这个对象结构,比如整个班级去献血,男生献血400ml,女生献血200ml;比如整个班级做学期评分,普通学生按照旷课和考试成绩评分,班长在此基础上有加分项,老师按照此学科及格、优秀率评分,班主任在此基础上有加分项;在比如班级植树活动,老师植树3棵,班长植树2棵,普通学生1棵树;这些功能明显会调用对象结构中每种对象的不同属性,但是这些功能并不适合封装在对象结构维护类中,但是随着这些类似的功能的增加,我们要考虑如何维护这些功能。
我们来总结一下,在上述应用场景里,有些功能需要访问目标(具体类、对象结构)的信息,但封装到具体目标中不仅会污染这些目标,还会随着功能的增到导致目标的臃肿不宜维护。我们可以对这些功能进行抽象封装,让他们去访问目标并完成自己的功能,同时也可以方便的扩展,针对这种场景,衍生出的设计模式即访问者模式。
访问者模