优化网站排名公司,江苏市场监督管理局,云南网络推广seo代理公司,官方网站建设条件如何以访客模式访问访客模式是面向对象设计中最被高估但又被低估的模式之一。 高估了它#xff0c;因为它通常选择得太快了#xff08; 可能是由建筑宇航员选择的 #xff09;#xff0c;然后以错误的方式添加后#xff0c;使原本非常简单的设计肿了。 如果您不遵循教科书… 如何以访客模式访问 访客模式是面向对象设计中最被高估但又被低估的模式之一。 高估了它因为它通常选择得太快了 可能是由建筑宇航员选择的 然后以错误的方式添加后使原本非常简单的设计肿了。 如果您不遵循教科书示例那么它可能会非常强大因此被低估了。 让我们详细看一下。 问题1命名 它的最大缺陷在我看来是命名本身。 “访客”模式。 当我们用google搜索它时我们很可能会在相关的Wikipedia文章中找到自己显示类似这样的有趣图像 维基百科访客模式示例 对。 对于我们98的人在日常软件工程工作中对车轮发动机和车身的思考而言这是显而易见的因为我们知道机修工向我们收取几千美元的汽车维修费用后我们将首先访问车轮然后是发动机然后最终访问我们的钱包并接受我们的现金。 如果我们很不幸他也会在我们工作时拜访我们的妻子但她永远不会接受那个忠实的灵魂。 但是解决工作中其他问题的2的人呢 就像我们为电子银行系统证券交易所客户Intranet门户等编写复杂的数据结构时一样。为什么不将访客模式应用于真正的分层数据结构 喜欢文件夹和文件 好的毕竟不是那么复杂 好的所以我们将“访问”文件夹每个文件夹都将让其文件“接受”为“访客”然后让访问者也“访问”这些文件。 什么 汽车让其零件接纳访客然后让访客自我参观吗 这些条款具有误导性。 它们是通用的适合设计模式。 但是它们会杀死您的现实设计因为没有人会考虑“接受”和“访问”而实际上您是在读/写/删除/修改文件系统。 问题2多态性 当应用于错误的情况时这比命名引起的头痛甚至更大。 访客为什么在地球上认识其他所有人 为什么访问者需要针对层次结构中每个涉及元素的方法 多态和封装要求将实现隐藏在API的后面。 我们数据结构的API可能以某种方式实现了复合模式 即其部分继承自公共接口。 好吧当然车轮不是汽车我妻子也不是机械师。 但是当我们采用文件夹/文件结构时它们不是全部都是java.util.File对象吗 了解问题 实际的问题不是访问代码的命名和可怕的API详细程度而是对模式的误解。 这不是最适合访问带有许多不同类型对象的大型复杂数据结构的模式。 这种模式最适合于访问几种不同类型的简单数据结构但要访问数百名访问者。 取文件和文件夹。 那是一个简单的数据结构。 您有两种类型。 一个可以包含另一个两者共享一些属性。 各种访客可能是 CalculateSizeVisitor FindOldestFileVisitor DeleteAllVisitor FindFilesByContentVisitor ScanForVirusesVisitor …你给它起名字 我仍然不喜欢命名但是这种模式在这种范例中可以完美地工作。 那么访客模式何时“错误” 我想以jOOQ QueryPart结构为例。 其中有很多可以对各种SQL查询结构进行建模从而使jOOQ可以构建和执行任意复杂度SQL查询。 让我们举几个例子 健康状况 组合条件 领域 表格栏位 字段清单 还有更多。 它们中的每一个都必须能够执行两个操作渲染SQL和绑定变量。 那将使两个访问者每个人都知道……40-50种类型…… 也许在遥远的未来jOOQ查询将能够呈现JPQL或其他某种查询类型。 那将使3位访客面对40-50种类型。 显然在这里经典的访客模式是一个错误的选择。 但是我仍然想“访问” QueryPart将渲染和绑定委托给较低的抽象级别。 那么如何实现呢 很简单坚持使用复合模式 它允许您向每个人都必须实现的数据结构添加一些API元素。 因此凭直觉第一步就是 interface QueryPart {// Let the QueryPart return its SQLString getSQL();// Let the QueryPart bind variables to a prepared// statement, given the next bind index, returning// the last bind indexint bind(PreparedStatement statement, int nextIndex);
} 使用此API我们可以轻松地抽象SQL查询并将职责委派给较低级别的工件。 例如一个BetweenCondition。 它负责在[lower]和[upper]条件之间正确排序[field]的各个部分语法正确地呈现SQL并将部分任务委派给其child-QueryParts class BetweenCondition {Field field;Field lower;Field upper;public String getSQL() {return field.getSQL() between lower.getSQL() and upper.getSQL();}public int bind(PreparedStatement statement, int nextIndex) {int result nextIndex;result field.bind(statement, result);result lower.bind(statement, result);result upper.bind(statement, result);return result;}
} 另一方面BindValue主要负责变量绑定 class BindValue {Object value;public String getSQL() {return ?;}public int bind(PreparedStatement statement, int nextIndex) {statement.setObject(nextIndex, value);return nextIndex 1;}
} 结合起来我们现在可以轻松创建这种形式的条件 在之间 和。 当实现更多QueryPart时我们还可以想象像MY_TABLE.MY_FIELD BETWEEN吗 与SELECTFROM DUAL在适当的字段实现可用时。 这就是使复合模式如此强大通用的API和许多封装行为的组件从而将行为的一部分委派给子组件的原因。 第2步负责API的演变 到目前为止我们已经看到的复合模式非常直观但是功能非常强大。 但是迟早我们将需要更多的参数因为我们发现要将状态从父级QueryPart传递给子级QueryParts。 例如我们希望能够内联某些子句的绑定值。 也许某些SQL方言不允许BETWEEN子句中的绑定值。 如何使用当前的API处理该问题 扩展它添加一个“布尔内联”参数 没有 这就是发明访客模式的原因之一。 为了使复合结构元素的API保持简单只需实现“接受”。 但是在这种情况下用“上下文”替换参数比实现真正的访客模式好得多 interface QueryPart {// The QueryPart now renders its SQL to the contextvoid toSQL(RenderContext context);// The QueryPart now binds its variables to the contextvoid bind(BindContext context);
} 上面的上下文将包含这样的属性setter和render方法返回上下文本身以允许方法链接 interface RenderContext {// Whether were inlining bind variablesboolean inline();RenderContext inline(boolean inline);// Whether fields should be rendered as a field declaration// (as opposed to a field reference). This is used for aliased fieldsboolean declareFields();RenderContext declareFields(boolean declare);// Whether tables should be rendered as a table declaration// (as opposed to a table reference). This is used for aliased tablesboolean declareTables();RenderContext declareTables(boolean declare);// Whether we should cast bind variablesboolean cast();// Render methodsRenderContext sql(String sql);RenderContext sql(char sql);RenderContext keyword(String keyword);RenderContext literal(String literal);// The contexts visit methodRenderContext sql(QueryPart sql);
} BindContext也是如此。 如您所见该API相当可扩展可以添加新属性还可以添加其他常见的呈现SQL的方法。 但是BetweenCondition不必放弃有关如何呈现其SQL以及是否允许绑定变量的封装知识。 它会将这些知识保留给自己 class BetweenCondition {Field field;Field lower;Field upper;// The QueryPart now renders its SQL to the contextpublic void toSQL(RenderContext context) {context.sql(field).keyword( between ).sql(lower).keyword( and ).sql(upper);}// The QueryPart now binds its variables to the contextpublic void bind(BindContext context) {context.bind(field).bind(lower).bind(upper);}
} 另一方面BindValue主要负责变量绑定 class BindValue {Object value;public void toSQL(RenderContext context) {context.sql(?);}public void bind(BindContext context) {context.statement().setObject(context.nextIndex(), value);}
} 结论将其命名为“上下文模式”而不是“访客模式” 快速跳到访客模式时要小心。 在许多情况下您将使设计变得肿从而使其完全难以阅读且难以调试。 这里是要记住的规则总结如下 如果您有许多访问者并且数据结构相对简单几种类型那么访问者模式可能就可以了。 如果您有很多类型并且访问者组相对较少很少有行为则访问者模式是过大的请坚持使用复合模式 为了简化API的演变请将您的复合对象设计为具有采用单个上下文参数的方法。 突然之间您将再次发现自己处于“几乎访问者”模式其中context visitor“ visit”和“ accept” “您专有的方法名称” 同时“上下文模式”与“复合模式”一样直观而与“访问者模式”一样强大结合了两个方面的优势。 参考 “访问者模式”是我们的JCG合作伙伴 Lukas Eder在JAVASQL和JOOQ博客上再次访问的 。 翻译自: https://www.javacodegeeks.com/2012/05/visitor-pattern-re-visited.html如何以访客模式访问
