代码之家  ›  专栏  ›  技术社区  ›  Mike

生成器模式使用不当?

  •  2
  • Mike  · 技术社区  · 14 年前

    对于一个设计模式类,讲师要求我的团队开发一个支持绘制和持久化glyphs的应用程序,非常类似于GoF的WYSIWYG编辑器。

    我的团队决定使用一个分层的体系结构,由下到下依次是:表示层、控制器层、逻辑层和持久性层。

    该逻辑维护一组字形表示、它们各自的位置和一些形状独特的属性。讲师建议我们使用Builder模式来创建统一的持久性机制,因为CSV和XML是必需的持久性格式。

    当我们试图在持久层中设计生成器时,问题就出现了。因为我们使用的是层,所以持久层不允许显式地了解Glyph类型,更不用说将它们从抽象形式转换为各自的形状。这让我绞尽脑汁,想知道如何将每个构建器作为其构造函数传递。

    下一个问题是很难概括生成器所采用的类型。矩形有直线没有的属性。

    编辑:

    1 回复  |  直到 14 年前
        1
  •  2
  •   Marjan Venema    14 年前

    我不确定你需要一个建筑工人。 工厂/注册中心和可序列化性 可能更切题。

    使持久化层忽略显式glyph类型的方法,同时仍然使其能够保存和加载特定的glyph实例,是通过某种 机制。要么是语言内置的东西(比如.NET中的反射,或者是Delphi/C++ Builder中的RTI),或者是手工制作的东西。

    要自己手工制作一个解决方案,你需要让所有的字形类型都从一个公共图形中派生出来 “可序列化”基类型 或者让他们都执行 “序列化”接口

    使用接口意味着glyph并不都需要公共基类型,使用公共基类型意味着您可以在该基类型中实现公共行为并避免一些重复。

    “可序列化”基类型或接口应为持久化层提供通过唯一(字符串)ID标识glyph类型的方法、对要持久化/加载的属性进行迭代的方法;以及多形式实例化glyph的方法(delphispeak中的虚拟构造函数和元类)。

    获取glyph类型id并迭代要持久化的属性对于保存实例来说应该足够了。

    访客 . 这可能会使生活更简单,当组成和聚合字形(分组在绘图应用程序)进入图片,没有双关语的意图:-)。关于这一点,你也可以考虑看看 模式,尽管对于你被要求做的事情来说,这可能是过分的。

    要从持久性存储中加载glyph,您将需要一个注册表,其中glyph类型与唯一名称(字符串)链接,以便持久性层可以从持久性信息中的字符串中查找要实例化的类型。每个glyph类型都需要在注册表中注册自己,以便持久层可以找到并实例化它。仰望 抽象工厂