珠海做网站设计,深圳网页制作案例,融资网站建设方案,iis 5.1 新建网站一、设计模式概念及设计原则 记得刚开始学编程的时候就看过设计模式相关的书籍#xff0c;虽然当时有很多地方都不理解#xff0c;但是建立了早期对架构设计的意识#xff0c;让后面的学习和工作中受益匪浅#xff0c;最近两年也一直在做架构设计方面的工作#xff0c;解开…一、设计模式概念及设计原则 记得刚开始学编程的时候就看过设计模式相关的书籍虽然当时有很多地方都不理解但是建立了早期对架构设计的意识让后面的学习和工作中受益匪浅最近两年也一直在做架构设计方面的工作解开了之前很多的困惑也形成了一些自己的思想我需要把自己零散的想法系统的整理出来如果能对大家有帮助当然更好了。为什么选择设计模式因为架构设计是一个很宽泛甚至对于有些人是一个很空虚的领域设计模式的好处就在早就已经有些很成熟被大家认可的模式。既然已经有了很成熟的模式我为什么还要重复造轮子呢目前网上很多关于设计模式的文章都是讲解各个模式的规则、目的很少有直接应用到实际工程的例子所以我在设计模式后面加了个最佳实践目的就是通过工程实践把自己在架构设计方面的积累转换成大家容易理解和熟悉的设计模式来表达出来。
1.1、面向对象六大设计原则
1、单一职责原则Single Responsibility Principle简称SRP 就一个类而言应该仅有一个引起它变化的原因。通俗的说即一个类只负责一项职责。这是一个备受争议却又及其重要的原则因为单一职责的划分界限并不是总是那么清晰很多时候都是需要靠个人经验来界定如何划分一个类、一个函数的职责每个人都有自己的看法这需要根据个人经验、具体的业务逻辑而定。但是它也有一些基本的指导原则例如两个完全不一样的功能就不应该放在一个类中。
2、开闭原则Open Close Principle简称OCP 对扩展开放对修改关闭。开闭原则是让程序更稳定、更灵活的一个基本保证。程序中的对象类、模块、函数等应该对于扩展是开放的但是对于修改是封闭的在软件的生命周期内因为变化、升级和维护等原因需要对软件原有代码进行修改时可能会将错误引入原本已经经过测试的旧代码中破坏原有系统。因此当软件需要变化时我们应该尽量通过扩展的方式来实现变化而不是通过修改已有的代码。
3、接口隔离原则InterfaceSegregation Principles简称ISP 客户端不应该依赖它不需要的接口一个类对另一个类的依赖应该建立在最小的接口上。为依赖接口的类定制服务只暴露给调用的类它需要的方法它不需要的方法则隐藏起来只有专注地为一个模块提供定制服务才能建立最小的依赖关系提高内聚减少对外交互使接口用最少的方法去完成最多的事情。接口尽量小但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实但是如果过小则会造成接口数量过多使设计复杂化所以一定要适度。
4、里氏替换原则Liskov Substitution Principle简称LSP 所有引用基类的地方必须能透明地使用其子类的对象。面向对象的语言的三大特点是继承、封装、多态里氏替换原则就是依赖于继承、多态这两大特性。里氏替换原则简单来说就是所有引用基类的地方必须能透明地使用其子类的对象。通俗点讲只要父类能出现的地方子类就可以出现而且替换为子类也不会产生任何错误或异常使用者可能根本就不需要知道是父类还是子类。但是反过来就不行了有子类出现的地方父类未必就能适应。说了那么多其实最终总结就两个字抽象。
5、依赖倒置原则Dependence Inversion Principle简称DIP 依赖反转原则指代了一种特定的解耦形式使得高层次的模块不依赖于低层次的模块的实现细节的目的依赖模块被颠倒了。这种表达真的让人很难理解简单点依赖倒置原则在 Java 语言中的表现就是模块间通过接口依赖实现类之间不发生直接的依赖关系。再简单点面向接口编程或者说是面向抽象编程
6、迪米特原则Law of Demeter简称LOD 也称为最少知识原则Least Knowledge Principle一个对象应该对其他对象有最少的了解也就是关于如何松耦合一个类应该对自己需要耦合或调用的类知道得最少类的内部如何实现、如何复杂都与调用者或者依赖者没关系调用者或者依赖者只需要知道他需要的方法即可其他的我一概不关心。类与类之间的关系越密切耦合度越大当一个类发生改变时对另一个类的影响也越大。
二、设计模式实践及总结
2.1、简单工厂模式 简单工厂模式 又称为 静态工厂模式 模式场景在一个披萨店中要根据不同客户的口味生产不同的披萨如素食披萨、希腊披萨等披萨。 凡是看到一个工厂Factory然后一个静态方法静态方法一个参数那么很可能就是用到了 简单工厂 模式。
2.2、工厂方法模式 client不需要知道具体产品只需要知道具体工厂 即可。 在披萨实例中如果我想根据地域的不同生产出不同口味的披萨如纽约口味披萨芝加哥口味披萨。如果利用简单工厂模式我们需要两个不同的工厂NYPizzaFactory、ChicagoPizzaFactory。在该地域中有很多的披萨店他们并不想依照总店的制作流程来生成披萨而是希望采用他们自己的制作流程。这个时候如果还使用简单工厂模式因为简单工厂模式是将披萨的制作流程完全承包了。那么怎么办 这样解决将披萨的制作方法交给各个披萨店完成但是他们只能提供制作完成的披萨披萨的订单处理仍然要交给披萨工厂去做。也就是说我们将createPizza()方法放回到PizzaStore中其他的部分还是保持不变。 示例有日志记录器 凡是看到AbstractProduct、AbstractFactory、ConcretetFactory 而且AbstractFactory 可以只能生产一个产品 很可能就是用到了 工厂方法 模式。
2.3、抽象工厂模式 依然是披萨店。为了要保证每家加盟店都能够生产高质量的披萨防止使用劣质的原料我们打算建造一家生产原料的工厂并将原料运送到各家加盟店。但是加盟店都位于不同的区域比如纽约、芝加哥。纽约使用一组原料芝加哥使用另一种原料。在这里我们可以这样理解这些不同的区域组成了原料家族每个区域实现了一个完整的原料家族。 各个区域的加盟店的同一款产品是一个维度是产品 等级结构 某个区域的加盟店的所有款产品是一个维度是产品 族。 抽象工厂类是不会涉及 加盟店的抽象产品类的所有产品构成 产品族。 加盟店是具体的工厂类是对抽象工厂类的实现。 凡是看到AbstractProduct、AbstractFactory、ConcretetFactory 而且AbstractFactory 可以生产多个产品 很可能就是用到了 抽象工厂 模式。
2.4、建造者模式 建造者模式构建复杂对象就像造汽车一样是一个一个组件一个一个步骤创建出来的它允许用户通过制定的对象类型和内容来创建他们但是用户并不需要知道这个复杂对象是如何构建的它只需要明白通过这样做我可以得到一个完整的复杂对象实例。 KFC里面一般都有好几种可供客户选择的套餐它可以根据客户所点的套餐然后在后面做这些套餐返回给客户的事一个完整的、美好的套餐。构造过程抽象统一为buildFoodbuildDrink 示例有游戏角色设计 凡是看到出现以Director、Builder结尾、或包含build、 construct方法 的类 很可能就是用到了 建造者模式。
2.5、原型模式 CtrlC、CtrlV、克隆、复制简历、复制Xxx。。。 示例有大同小异的工作周报、带附件的周报 凡是看到出现以Prototype结尾、或包含clone、copy方法 的类 很可能就是用到了 原型模式。
2.6、单例模式 如果制造出多个实例会导致很多问题产生的情况。 通常是重量级的类比如tomcat的ServletContextHibernate的SessionFactorySpring的BeanFactory通常只有一个。 单例模式一般通过静态的实例变量来实现可以想象的是如果这个全局唯一的 静态的实例变量 能够保证其创建的 其他Subject比如Bean也是只有一个 那么那些Subject 也是单例的 尽量“那些Subject” 本身并本身 单例模式~ 比如 我们Spring 容器中的单例的Bean。 单例的Bean 并不是设计模式中单例模式 只是其scope是 Spring 容器唯一。这个是两码事大家应该还 是能够区分清楚的吧 Spring 容器何保证其单例的Bean每次获取得到的 都是同一个 一般我们的通过缓存 即缓存到内存。 通过“ Spring 容器中的单例的BeanSpring 容器中的单例的Bean ”这样的方式 我们实际上可以实现一个 单例链或 单例实例链 最开始的某些对象是静态单例的其创建的bean 不是单例不是静态却是唯一的bean 可以 创建其他 “ bean 不是单例不是静态却是唯一的 ” 过程反复 就形成了一个链条。 当然我们说全局 这个局有多大仍然是个相对的概念。 示例有太多 凡是看到 Singleton getSingleton 很可能就是用到了 单例模式。 虽然实践中 不一定使用 Singleton 这个词 但这个是常见的。是良好的实际。
2.7、适配器模式 我们工作电压11V的电脑需要在 220V的 输电电压下 工作 我们就需要 电源适配器 机器人想要模拟人的操作那么也需要进行 某些适配工作。 示例有没有源码的算法库 Target 虽然常见但是我们一般不会使用这个词而是直接使用我们实际的类的名称。凡是看到出现以Adapter、Adaptee结尾、或包含requestspecialRequest 方法 的类 很可能就是用到了 适配器 模式。尽管如此我们实际中可能不会使用 requestspecialRequest 这样的词 而是直接、具体的 接口名字。
2.8、桥接模式 假设图形类有两个关键属性 形状、颜色。我们有 正方形、长方形、圆形有三种颜色白色、灰色、黑色那么我们可以画出3*39中图形。 那么 我们是不是就需要九个 class类呢 不需要的通过桥接模式我们只需要 33 6 个类。 可以想象如果形状、颜色 更多那么 桥接模式 就非常有效的减少了类的数量。 桥接模式 好像和 装饰模式有异曲同工之妙它们都可以有效的减少了类的数量 防止类数量爆炸。 但是这里的例子中装饰模式是不合适的 因为 形状、颜色 是两个独立的属性没有任何相关关系的。 桥接模式 是对 不同属性 从不同维度的 拆分。属性之间 仅仅是一个 聚合关系。 装饰模式 是对 不同行为围绕某个主要行为 进行 装饰。需要有继承or实现关系。 示例有跨平台图像浏览系统 凡是看到出现以RefinedAbstraction、Implementor结尾 的类 很可能就是用到了 桥接模式。 虽然实际中 很可能不会使用 RefinedAbstraction、Implementor 这样的词来命名我们的类名但是 仍然可以做一个判断。
2.9、组合模式 凡是涉及文件系统的浏览遍历、操作等的 比如 杀毒软件对 文件系统进行杀毒。 语法树比如XMLHTMLJSON 常常存在 “容器” 元素 就很适合 组合模式 。比如 HTML 语法树我们可以把 div 当做一个 容器div 可以嵌套各种子元素。 示例有Configuration、Bean、Component 凡是看到出现以Composite、Leaf、combination、assembly、group结尾、或包含filter、 handle、intercept 方法 以及 add、remove、getChild 方法 的类 很可能就是用到了 装饰器模式。
2.10、装饰器模式 需要动态地给一个对象增加功能这些功能也可以动态地被撤销。 当不能采用继承的方式对系统进行扩充或者采用继承不利于系统扩展和维护时。 装饰者模式的关键词 一定是“动态、灵活” 通过继承我们可以做很多事情但是显得十分臃肿十分不动态类数量m*n爆炸。装饰者模式可以避免这些 将类数量 变化 m n 其实装饰模式和适配器模式都是“包装模式(Wrapper Pattern)”。 另外代理模式好像也有包装 功能但是要求、侧重点是不同的。 示例有图形界面构件库 凡是看到出现以Decorator、Filter、Interceptor 、Wrapper 结尾、或包含filter、 handle、intercept 方法 的类 很可能就是用到了 装饰器模式。
2.11、外观/门面模式 非常笼统而宽泛的模式 示例有B/S系统的首页等等 凡是看到出现以Facade、System、Manager 结尾 的类 很可能就是用到了 外观/门面模式。 没错这里有个Manager Manager 是一个范畴很大的词。
2.12、享元模式 其实就是 对一系列类似的 对象 实现了 单例模式 然后统一管理。 示例有ThreadLocalRedis缓存。http、redis、mq、kafka、String常量池、数据库连接池、缓冲池 凡是看到出现以Flyweight 结尾 的类 很可能就是用到了享元模式。实践中我们可能不会使用Flyweight这样的词而是具体的 “ 元 ” 的类名 而判断是否是 享元 关键是 判断是否有一个 map 存在 其 get 方法是否会判断“元” 是否已经存在是否包含了 put 操作。
2.13、代理模式 web 代理服务器、Nginx反向代理JDK动态代理CGlib 动态代理 1、 远程代理为一个对象在不同的地址空间提供局部代表。这样可以隐藏一个对象存在于不同地址空间的事实。 2、 虚拟代理通过使用过一个小的对象代理一个大对象。这样就可以减少系统的开销。 3、 保护代理用来控制对真实对象的访问权限。 示例有收费商务信息查询系统 凡是以Proxy 结尾或看到出现包含preRequestpostRequest 等 preXxx、postXxx 方法 的类或看到 InvocationHandler 很可能就是用到了代理模式。
2.14、职责链模式 凡是那些涉及 不同等级层次的 操作、流程不同等级有不同权限、功能或需要 层层审批。那么就适合。 示例有采购单的分级审批、请假流程、报销审批流程。。。 凡是看到出现以Chain、pipeline 结尾、或包含handlerhandleRequest 方法 的类 很可能就是用到了责任链模式。
2.15、命令模式 Invoker (调用者)本来可以直接调用Receiver(接收者) 但是Invoker 觉得麻烦不想、不需或不能 管太多 那么我们引入一个 Command 中间层那么 就实现了解耦。 一些场景控制面板、遥控器 示例有自定义功能键、撤销操作、宏命令 凡是看到出现以Command、Order 、Invoker、Receiver 结尾、或包含execute、call、action 方法 的类 很可能就是用到了 命令模式。
2.16、解释器模式 语法分析解释权、抽象语法树翻译机。对不懂的外国语进行 翻译。等等 示例有机器人控制程序 凡是看到出现以Expression/ translate/ interpret 结尾、或包含 translate/ interpret 方法 的类 很可能就是用到了 解释器模式。
2.17、迭代器模式 Aggregate和 Iterator 分离。为什么需要分离 Iterator 不需要知道Aggregate的数据是怎么来的 可以按照需要的 方式进行遍历。 比如对电视机的各个有限电视台的遍历我们可以 按照 各个省、地方电视台的顺序一个省的所有电视台遍历完了之后再其他省 也可以按照 先遍历所有省的 娱乐频道然后遍历所有省的 经济频道然后。。 HaspMap的 迭代器。 示例有JDK内置迭代器、销售管理系统中数据的遍历 凡是看到出现以Iterator、Loop 结尾、或包含hasNextnexthasMore方法 的类 很可能就是用到了 迭代器模式。
2.18、中介者模式 中介就是我们平常所理解的 中介。适合某些 双方/多方 不宜 直接对话的情况。 中介者 当然需要一定的 权威性、权力、公信度。 同事之间 虽然可以直接1对1,沟通但某些时刻需要通过部门负责人来 中介、协调。同学之间 需要通过 辅导员、班主任来沟通、 统一领导、指挥。男方和 女方 通过婚介所 进行联谊。 租房者与房屋所有者之间通过 某些 中介机构 来交互、沟通。求职者和 用人企业之间 通过求职网站、猎头 充当中介。 国与国之间的关系异常复杂联合国 可以算是一个 中介。等等 实际生活中我们常常把 中介和 代理混为一谈因为有时候确实是 很难区分但是设计模式中我们不为因为我们需要满足uml 的限制当然我们也不一定拘泥于 uml。 Agent 到底是代理 还是中介讨论这个问题没有意义。 示例有协调者 凡是以Mediator、Colleague、middleManAgent 结尾的类 很可能就是用到了 中介 模式。当然colleague的语义比较窄 我们可能并不会使用这个词而是其他类似的词。比如 同窗同僚co-authorco-workercounterparter 。
2.19、备忘录模式 某些对象你想保存下来 但是对象的的内部状态比较复杂 你记不住 不方便直接操作器状态 这个时候我们可以使用 备忘录Memento把它“录”下来以防“备忘” 但是呢备忘录模式的 备忘录本身没有备忘的 功能备忘的功能 由 负责人Caretaker 提供。所以说备忘录模式 跟我们 实际生活 用到的 备忘录 其实并不对等。 如果非要对应起来的话那么 “实际生活 用到的 备忘录 ” 对应 备忘录模式的Caretaker但是“ 实际生活 用到的 备忘录 ” 并没有 restore 功能 这个需要人来做相对于是 save、 restore 功能分离了。 场景 需要撤销动作的 对象 示例有游戏存档 Originator这个词很少见Mememto 也不多见只要看到了它们或者save 同时 restore 这个关键字 很可能就是用到了 备忘录模式。
2.20、观察者模式 观察者模式又称为发布-订阅模式。 观察者 太多了。观察 太常见的动作了所以 观察者模式 是我们时时刻刻都在用到的只不过用得太多没感觉了向空气一样感觉不到它的存在了比如吃饭看饭下菜你看电视然后随着剧情喜怒哀乐开车根据路标指示做不同的操作观察明天的天气看看去哪里玩 合适观察研究不同股票的表现决定买入还是卖出还是等待随心而动、随性而为。。 jdk是有提供 ObserveableListener、消息队列MQ。。。 使用观察者模式天然的 就将 被观察目标 和 观察者 解耦了 但是呢我们实际软件开发的过程中并不是说 用眼睛观察一下看一下就完了貌似只消耗了一些光子没有和 Subject产生 任何关系并不是说 Subject和 Observer 完全没有关系Subject 是必须依赖Observer 的一般来说Subject对象 拥有 Observer 对象的集合。 另外我们需要注意实际软件开发中 观察者 是可以出现异常的观察到事件但是处理发生了异常 这个时候呢 应该观察者Observer 是不应该影响到 Subject 的继续运行的也就是说 Observer 需要处理所有异常 而不应该 抛给Subject 。 观察者模式 和 监听模式 几乎是一个意思。 观察者 就是 监听器。 观察者模式 和 事件驱动 几乎可以认为是 同义词。观察者模式 中虽然 没有体现出来 事件 但是 具体主题发生改变时会notify 所有的 监听者、观察者 给所有的观察者发出通知 这个通知 其实就是 可以认为是一个 事件。 示例有XxxListener 凡是看到出现以Event、Listener结尾、或包含notify、update、observe、onXxxEvent方法 的类 很可能就是用到了 观察者模式。
2.21、状态模式 状态模式 主要是把 对象的 状态 独立了出来成了 状态类 每个状态 都需要处理当前状态下的 一些具体事情对外表现不同的行为所以 State 有一个 handle 方法 每个ConcreteState 需要实现它。 状态模式 的核心要义并不是 状态类 而是 不同状态之间的切换。Context 发起状态切换ConcreteState 完成具体的操作。 酒店房间Room有预定book、取消预定unbook、入住checkIn可继续细分为住满未住满、单人状态等待双人拼房、更换房间、退房checkOut等 必要的接口操作有 空闲、预定、入住 等状态 不同状态 对 客户请求是不一样的空闲状态是可以预定、直接入住的但是不能退房。预定状态可以 入住、更换房间、取消预定但是不能退房已入住状态 不能再 预定、取消预定、入住 只有一个退房操作。 Context可以自己直接转换状态但一般来说是交给State 去handle。具体来说Room可以提供一个 setState 接口或者提供 多个具体的接口bookunbook checkIncheckOut等显然后者更加合理。 实际呢 我看到使用更多的是Constants、Enum 这样的常量、枚举类它们其实是可以转换为状态模式的。 而且如果 行为比较复杂 改为 状态模式 应该会更好一些。 状态模式 是否 可以完全的 取代 枚举类 当然是不能的比如我一个很简单的东西 一个星期有7天分别是Monday、Tuesday、Wednesday、Thursday、Friday、Saturday、Sunday 这样简单的枚举并不涉及任何复杂的具体的 行为、操作 用一个枚举就蛮好的星期几一般不会用作为一个状态不会影响对象的行为。没必要状态模式。春夏秋冬东南西北都不是状态。 状态模式 关键是状态的选取状态一定是影响对象 对请求的响应的。关键要理解 状态是否可以独立出来状态改变对 对象行为的 影响。 状态模式 说白了就是 把一个很大的if else 语句块变成了 比较小的if else 语句块但是 if else 语句块 仍然存在不符合 开闭原则。 示例有银行系统中的账户类设计 凡是以State结尾的类 很可能就是用到了 状态模式。当然这个是不一定的我们可能会使用诸如 Status、Way、Method、Operation 这样的次。
2.22、策略模式 策略模式关键是需要理解 策略。这里的策略并不是说指挥三军打仗的 谋略也不一定要 国家颁布了 新的房地产发展规划指南 才能算是策略。而是说 做一件事情的 不同的方式方法。 比如我吃饭可以拿筷子吃也可以直接手抓着吃可以拿盘子盛着可以拿碗可以拿杯也可以直接拿锅 去韩国旅行可以坐飞机、铁路、公路海路等等都可以是策略。 当然我们还可以把策略理解为 算法。我需要排序一个数组可以冒泡算法、可以选择算法等等。 我们关注目的只要目标达成了就好了不同的策略 给与我们不同的选择让我们 灵活切换。 示例有电影票打折方案 凡是以Strategy结尾的类 很可能就是用到了 策略模式。或者algorithm 结尾。
2.23、模板方法模式 如果你做了很多类似的有一定重复工作的事情 但又不完全相同的比较固定的操作流程 而且以后也还要经常做那么可以考虑 提取出来一个模板方法把高层级的某些 操作顺序、流程 固定化然后 把具体的不同的工作 在实际操作的时候 去细化去完成那么这就是 模板方法模式。 模板方法模式 强调 模板。必须是能够提取出来一个做事、操作的模板 才比较合适。 一些场景有比如每个人都要经历 出生-学校读书-工作-退休-去世 等过程这些基本是固定的 但是具体的操作非常不一样。 当然这样的例子 太宽泛了 不容易进行细致讨论。 比如很多人的每天就是 起床-洗漱-早餐-坐公交/地铁去公司-工作-午餐/午休-工作-坐公交/地铁回家-晚餐-休息-睡觉 的这样的routine 对这些人我们可以套用一个模板当然对于其他人这个模板可能就不适用了 往细一点说我们java 使用数据库都有固定的几个步骤 连接数据库、获取datasource、获取connection、创建statement、执行sql、获取结果resultset、关闭connection除了 执行sql 按照具体情况很大不同之外其他步骤基本是相同的因为spring 为我们封装了JDBCTemplate。等等。 示例有JDBCTemplat、银行利息计算模块 凡是XxxTemplate这样的 以Template结尾的类 很可能就是用到了 模板方法模式。
2.24、访问者模式 现在 我们作为游客Vistor去景区旅游。景区有很多景点Element每个景点呢需要收取不同的票价、有不同的景观、有不同的接待accept方式游客Vistor呢可以选择 任意一些景点然后进行 游览visit。我们可以都选择独立游或自驾游但是这样呢景区会比较乱而 不好做规划。我们可以选择导游。导游ObjectStructure可以帮助我们完成这个过程。 Element景点的一般操作是制定门票价格、接受 游客 进入游玩acceptaccept方法的参数正是 Visitor 游客 ConcreteElement具体景点的作用是设置具体的 门票价格提供各种游玩场所和设施接受游玩。 Vistor游客的一般操作是买票、访问visit visit 方法的参数正是 Element景点某个 / 某些 景点 ... ConcreteVisitor具体游客的作用是花实际的价钱买票选择具体的 景点而不是全部。 ObjectStructure导游的作用是对象结构包含了一个景区List 提供add、remove接口可以动态增删能够枚举各个景点然后 同样提供 accept 接待访问的接口 然后 遍历 list 以供游客访问景区。 这样我们可以 方便的增加 景点和 游客。 好像没有任何的问题。 但是uml 中 Vistor游客的访问方法的参数 是具体景点ConcreteElement而不是Element。可以认为ConcreteElementA是 歌剧表演、B是山水、C是舞蹈魔术 Vistor 做了这么一个限定提供三个接口任何游客可以访问3个类型景点。 每个具体类型景点 需要标明自己是类型比如 门口标志 需要特定服装才能进入、仅限儿童进入等等也就是说景区为了牟利并不管你是 儿童还是老人都可以给你推荐 儿童乐园。 景区 尽量让游客把每个景点都至少玩一遍。 Vistor游客也可以分类比如儿童、年轻人、老人儿童有儿童的游玩方式、年轻人、老人游玩方式都不同。 还可以这样分类 A儿童景点B是年轻人景点C是老人景点。 这个模式有一点不好的是 不管Vistor是否愿意它需要把所有具体的Element的访问接口准备好。当然这仅仅是准备并一定要实际的去访问 提供访问的可能性。但这个是比较麻烦的因为游客可能根本不需要去访问它不管怎么样景区还是要把 景点 推广出去。如果我们 增加了一个类型 景点比如惊险刺激类的过山车那么 所有的ConcreteElement都要做变化 破坏了开闭原则。 这个例子可能并不太好实际情况我们可以有那种不得不访问的情况比如 买房过程一般来说必须要去 房产销售中心商谈、去商品房的实际地点看看毛坯房、 去房管局登记 / 缴税费 / 拿发票 等 每一个步骤的接口 都是开放的 买房者需要去准备去实现之虽然不一定马上就去做不一定立即调用 各个 visit 方法。如果政府规定了买房必须去中国银行 报备那么 买房者还需要去准备 一个 访问 中国银行的接口。 另外访问者模式 的访问不一定的 访问也可以是 交互、。。 示例有OA系统中员工数据汇总 凡是看到 Visit、ObjectStructure 很可能就是用到了 访问者方法模式。
