【问题标题】:The delegates need the methods and attributes of the holder class委托需要持有者类的方法和属性
【发布时间】:2014-10-08 09:04:18
【问题描述】:

我有一些实体,取决于内部结构,它可能以两种方式起作用。例如,我的 Connector 类可以作为 HttpConnector 和 TCPConnector 运行。这两个“引擎”类的“连接”方法的实现不同。它们都共享一些Connector的常用方法,例如“openFileToTransfer(String fileName)”,并共享通用属性,例如“folderWithFiles”等。我需要两个找到解决这个问题的最佳OOP设计。

1) 第一种方式是委托。我用 TCPConnectorEngine 创建了连接器,它可以工作。问题是我需要分享一些设置和常用方法。我当然不想将它们复制粘贴到每个类中。我可以通过构造函数提供通用设置,这意味着对相同的属性进行两次编码,但共享通用方法更难。也许我可以在它们每个中注入连接器实例,但这看起来很难看。也许我可以为我的两个连接器引擎提供一个 BaseClass,但这看起来更复杂。

2) 第二种方式是继承。我只是从 Connector 继承 TCPConnector 并得到我需要的一切。但我认为“引擎”决定更适合我的任务,因为它更符合逻辑。它真的是一个连接器的引擎,它不是不同类型的连接器..但可能是我错了吗?

您会选择哪种方式,为什么? 如果对答案很重要,我会使用 Java。

【问题讨论】:

    标签: oop inheritance design-patterns delegates


    【解决方案1】:

    在模式术语中,问题归结为,如何正确实现Connection 接口:

    1) 使用facade,然后委托给strategy

    2) 或者使用抽象基类并通过具体实现继承。

    所以在我的意见 2 是一个很好的解决方案,只有在 chil 类的内部编排或协议非常相似并且因此它们可以共享大量结构和代码的情况下,这就是在基类中捕获。

    如果内部使用的概念完全不同,我认为最好实现不同的策略,将它们实例化在 facade 类中并委托给 strategy 个实例。如果您想要代码重用,例如对于设置,我会将这个概念保留在不同的类中,例如ConnectionSettings 并将其从外观注入到策略实例中。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2012-05-17
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-12-03
      相关资源
      最近更新 更多