有关此主题的Stackover流相关文章:
Post_1Post_2

上面的帖子很好,但是仍然无法解决我的困惑,因此我将其作为新帖子放在这里。
我的问题是基于GOF关于可插拔适配器的可重用的面向对象软件元素的书(在下面的问题之后提到),因此,如果我们的讨论/答案/评论更集中于GOF关于可插拔的现有示例,我将不胜感激。适配器,而不是其他示例
Q1)内置接口适配是什么意思?
Q2)与常规适配器相比,可插拔接口有何特殊之处?通常的适配器还可以使一个接口适应另一个接口。
Q3)即使在这两种用例中,我们都根据GetChildren(Node)看到了提取的“窄接口” CreateGraphicNode(Node)Node的两种方法。 Node是Toolkit的内部组件。 Node是否与GraphicNode相同,并且在CreateGraphicNode中传递的参数仅用于填充已经创建的Node对象的状态(名称,parentID等)吗?

根据GOF(我用粗体字标记了一些单词/句子以强调与我的问题相关的内容)

ObjectWorks \ Smalltalk [Par90]使用术语
可插拔适配器,用于描述具有内置接口适配的类。

考虑一个可以以图形方式显示树结构的 TreeDisplay 小部件。
如果这是仅用于一个应用程序的专用小部件,则
我们可能要求它显示的对象具有特定的接口;
也就是说,所有这些都必须来自Tree抽象类。但是如果我们想
使TreeDisplay更具可重用性(例如,我们希望使其成为工具包的一部分
有用的小部件),那么该要求将是不合理的。
应用程序将为树结构定义自己的类。他们
不应被迫使用我们的Tree抽象类。不同的树
结构将具有不同的接口。

可插拔适配器。让我们看一下实现可插拔适配器的三种方法
用于前面描述的TreeDisplay小部件,可以进行布局和显示
自动分层结构。
第一步,对于所讨论的所有三个实现都是通用的
在这里,是找到Adaptee的“窄”界面,即最小的
我们可以进行调整的部分操作。狭窄的界面
仅由几个操作组成的操作比
与数十种操作进行交互。对于TreeDisplay,适应者是任何
层次结构。简约界面可能包括两个
操作,它定义了如何在层次结构中显示节点
以图形方式显示结构,另一个用于检索节点的子级。

然后有两个用例

  • 作为抽象显示的“窄接口”,它是TreeDisplay的一部分

    java - GOF中提到的可插拔适配器-LMLPHP
  • 窄接口提取为一个单独的接口,并在TreeDisplay类中包含它的组成
    java - GOF中提到的可插拔适配器-LMLPHP

  • (还有一种第三种方法是使用参数化适配器,但为简单起见,请跳过它。另外,我猜这第三种方法是更专门针对Small Talk的)

    最佳答案

    在谈论适配器设计模式时,通常会考虑两个我们希望集成的预先存在的API,但它们并不匹配,因为它们是在不同的时间用不同的域实现的。适配器可能需要做很多从一个API到另一个API的映射,因为这两个API在设计时都没有考虑到这种可扩展性。

    但是,如果Target API的设计考虑了 future 的适应性,该怎么办? Target API可以通过最小化假设并为适配器实现最窄的接口来简化将来的适配器的工作。请注意,此设计需要先验规划。与适配器模式的典型用例不同,您不能在任何两个API之间插入可插拔适配器。 Target API必须已设计为支持可插拔适配。

    Q1)这就是GoF通过内置接口适配的含义:Target API中内置了一个接口,以支持将来的适配。

    如前所述,对于适配器来说,这是一个相对不常见的场景,因为模式的典型优势在于它能够处理没有通用设计的API。

    GoF列出了三种设计适应性Target API的方法。前两个可识别为两个行为设计模式。

  • 模板方法
  • 策略
  • 闭包(Smalltalk称为code blocks)

  • Q3)在不了解GoF的GUI示例细节的情况下,设计所谓的“窄接口”背后的基本思想是消除尽可能多的域特异性。在Java中,与域无关的API的起点几乎可以肯定是functional interfaces

    与围绕这些接口的依赖关系相比,依赖于这些接口的Target API应当更容易适应。前者允许创建可插拔适配器,而后者则需要具有API之间重映射的更典型的适配器。

    10-06 06:11