设计模式，就这么回事—

需求：优酷要求设计一个不同用户可以观看不同类别的视频资源的系统，这应该要用访客模式吧。
分析1：
一上来，先来个小学生的分析思维：得有不同的用户类，比如普通用户，黄金用户，钻石用户，视频资源有普通视频，黄金视频，钻石视频。（钻石视频就是说钻石用户可看）对于不同的用户，展开鉴权。好了，开工：

class 用户（）
{   看视频（视频）     }class 普通用户（）
{看视频（ 视频 ）{if 视频 == 普通视频 可以看；if 视频 == 黄金、钻石  不可以看；}
}
class 黄金用户（）
{看视频（ 视频 ）{if 视频 == 普通 黄金视频 可以看；if 视频 == 钻石  不可以看；}
}
class 钻石用户（）
{看视频（ 视频 ）{管你什么视频 都可以看；}
}当然还有一些视频类：
class 普通视频，黄金视频，钻石视频；//这样使用：
小明 = 普通用户（）
视频 = 普通视频（）
小明.看视频（ 视频 ）    OK
视频 = 黄金视频（）
小明.看视频（ 视频 ）    NO

完工！感觉还可以。这算访客模式吗？当然不算！
优酷老总提要求了，说是要增加一档特别节目，比如成人节目，只允许红宝石用户观看，看看怎么修改代码：卧槽，代码全要改动：
首先要增加一个成人节目类；还要增加一个红宝石用户类；这些不说，坑爹的是所有之前的鉴权代码都要改，对于每一个用户，都要对所有视频进行遍历鉴权；。。。大概如下：

class 成人视频（）{ 。。。 }
class 红宝石用户（）{ 。。。 }
class 普通用户（）
{看视频（视频）{if 视频 == 普通视频 可以看；if 视频 == 黄金、钻石  不可以看；//添加的部分if 视频 == 成人视频 不可以看；}
}
其他所有用户都要这样改。。。
如果哪天又推新节目，就废了。。。

评价1：上述方法，符合人的直观思维，易于理解。不过大量重复，也无封装、动态可言，实则是面向过程的设计。

分析2：
分析一下系统，特点如下：用户是变动的，视频是变动的，用户要和视频发生关系。并且视频的变动大于用户的变动。这很适合用访客模式。
这里主要解决的是，如何让视频的变动不影响用户的代码，如何让视频的变动不影响用户的代码。
先看第一个，如何让视频的变动不影响用户。之前的系统是做不到这一点的，用户在代码中遍历了视频，视频改了用户代码也得改。其实，如果是用户 “访问”视频的话，用户就依赖视频，免不了跟着视频改动。何不转换一下思维方式，让视频 ”访问“ 用户——对用户进行鉴权。这样，就变成视频依赖用户，至少可以解决第一个问题，就是视频变化不影响用户了。第二个问题如何解决后面再说。
好了，开工：

class 普通用户，黄金用户，钻石用户。。。随便加。。
//重点在下面
class 普通视频（）{看视频（ 用户 ）if 用户 在普通之上  可以看；
}
class 黄金视频（）{看视频（ 用户 ）if 用户 在黄金之上  可以看；
}
其他类似。
为了配合视频 “操作” 用户的这一特殊功能，我们得把用户类稍作改动。以普通用户为例，其他同。
class 普通用户（）{看视频（ 用户自己 ， 视频 ）视频.看视频（ 用户自己 ）
}
//上面是精华：在用户中，并不需要自己实现鉴权行为，而是交给 视频 类去处理，
//为了让 视频 能认识自己，还把自己作为参数传了进去，这下视频端就可以实现对用户的鉴权了。那么怎么使用呢，像这样：
小明 = 普通用户（）
视频 = 普通视频（）
小明.看视频（ 视频 ）  OK~
视频 = 黄金视频（）
小明.看视频（视频）  NO!//如果哪天添加视频种类了，只需要这样即可
视频 = 成人视频（）
小明.看视频（ 视频 ）
//根本不需要改用户代码，所有鉴权操作在 成人视频 中完成。

到这里，解决了一大问题，还有一个问题是，如何让用户的改动不影响视频，现在视频类中要对所有用户鉴权，视频其实是依赖用户的，对这种依赖的一个应对策略就是保证用户类别的稳定性。没有什么办法比这个办法更好了。
是在不行，再使用如下方法：
在视频类中，放一份用户类别列表，这份列表由用户工厂维护。视频类需要从用户工厂中获取到这个列表，然后对里面的用户遍历鉴权。这样也能做到即使用户变化了，视频类也无需改动，因为视频类内部处理的是用户列表，至于有几个用户，无关紧要。
大致如下实现视频类：

class 视频（）{用户列表 = 用户工厂.get用户列表（）for 用户 in 用户列表{鉴权。。}
}

到此，两大问题都解决了。设计完之后，聪明的你可能会发现，用户和视频地位其实是对等的。能用视频访问用户的思路解决问题，其实原来的用户访问视频也能解决问题。的确如此，用户访问视频模式，首先用户的变化不影响视频，其次，用一个视频列表就可以解决视频的变化不影响用户。只不过，访客模式强调的访客的稳定性，即这里的用户是稳定的，如果要设计，就得让用户成为被访问对象。说白了，两个类发生关系，哪个类稳定，就让哪个类充当被处理者。这，就是访客模式。

设计模式，就这么回事——访客模式相关推荐

访客模式无痕模式区别_旧访客设计模式的新生活
访客模式无痕模式区别介绍访客 [1.2]是众所周知的经典设计模式. 有很多资源对其进行了详细说明. 在不深入研究实现的情况下,我将简要提醒一下该模式的概念,解释其优点和缺点,并提出一些可以使用 ...
访客模式无痕模式区别_访客设计模式示例
访客模式无痕模式区别本文是我们名为" Java设计模式 "的学院课程的一部分. 在本课程中,您将深入研究大量的设计模式,并了解如何在Java中实现和利用它们. 您将了解模式如 ...
Go设计模式--访客模式
大家好,这里是每周都在陪你一起进步的网管-!今天继续学习设计模式-访客模式访客模式也叫访问者模式(Visitor Pattern)是一种将数据结构对象与数据操作分离的设计模式,可以在不改变数据结构对 ...
访客模式无痕模式区别_访客设计模式
访客模式无痕模式区别我猜想很多人都知道来访者设计模式,这在<四人帮的设计模式:可重用的面向对象软件的元素>一书中有描述. 模式本身不是很复杂(随着许多设计模式的发展): 我很久以来就 ...
访客模式无痕模式区别_行为设计模式：访客
访客模式无痕模式区别行为设计模式的最后一个模式将是访客模式. 当我们希望能够在不更改类的情况下为对象结构的类定义新操作时,使用访问者模式. 想象一下执行对api的http请求的软件的场景. 大多 ...
java 访客模式,设计模式 - 访客模式( Visitor Pattern)
设计模式 - 访客模式( Visitor Pattern) 在Visitor模式中,我们使用一个访问者类来更改元素类的执行算法. 通过这种方式,元素的执行算法可以随着访问者的变化而变化. 此模式属于行 ...
GOF23 设计模式之命令模式、解释器模式、访客模式
这三种模式不常用命令模式: 把一个请求封装成对象,也可以把很多个请求封装成对象,然后对这写请求命令进行的处理 (请求排队,记录日志,撤销) 应用场景: 数据库的事务 ,命令的撤销和恢复 ***** ...
unity3d 收费模式_unity3d中的访客模式
unity3d 收费模式抽象 (Abstract) Game development as a discipline is challenging on its own compared to tr ...
如何以访客模式访问_重新访问了访客模式
如何以访客模式访问访客模式是面向对象设计中最被高估但又被低估的模式之一. 高估了它,因为它通常选择得太快了( 可能是由建筑宇航员选择的 ),然后以错误的方式添加后,使原本非常简单的设计肿了. 如果您 ...

设计模式，就这么回事——访客模式

设计模式，就这么回事——访客模式相关推荐

最新文章

热门文章