问题描述
与此主题相关的Stackover流相关文章：
将窄界面提取为单独的接口，并在TreeDisplay类
中包含它的组成
（还有第三种方法是使用参数化适配器，但为简单起见，跳过了它。另外，我猜这第三种方法更具体到闲聊）
在讨论适配器设计模式时，通常会考虑两个我们希望集成的预先存在的API ，但它们不匹配，因为它们是在不同的时间用不同的域实现的。适配器可能需要做很多从一个API到另一个API的映射，因为这两个API的设计都没有考虑到这种可扩展性。
但是如果 Target API的设计考虑了未来的适应性吗？ Target API可以通过最小化假设并为Adapters实现提供最窄的接口，从而简化将来的Adapters的工作。请注意，此设计需要先验规划。与适配器模式的典型用例不同，您不能在任何两个API之间插入可插拔适配器。 Target API必须设计为支持可插拔适配。
第一季度） GoF是内置接口改编的意思： Target API中内置了一个接口，以支持将来的改编。
Q2）如前所述，对于适配器来说，这是一个相对不常见的情况，因为该模式的典型优势是它能够处理没有接口的API。
GoF列出了三种不同的方法来设计用于适应的 Target API。前两个可以识别为它们的一些行为设计模式。
- 模板方法
- 策略
- 关闭（Smalltalk称之为 ）
第三季度）在不了解GoF的GUI示例细节的情况下，设计背后的基本思想他们称其为窄接口是为了消除尽可能多的域特异性。在Java中，与域无关的API的起点几乎肯定是。
A Target API，它们依赖于与基于特定于域的方法构建的API相比，这些接口的适应性应该简单得多。前者允许创建可插拔适配器，而后者则需要具有API之间重映射的更典型的适配器。
The related Posts on Stackover flow for this topic :Post_1 and Post_2
Above posts are good but still I could not get answer to my confusion, hence I am putting it as a new post here.
MY Questions based on the GOF's Elements of Reusable Object-Oriented Software book content about Pluggable Adapters (mentioned after questions below), hence I would appreciate if the discussions/answers/comments are more focused on the existing examples from GOF regarding the pluggable Adapters rather than other examples
Q1) What do we mean by built-in interface adaptation ?
Q2) How is Pluggable Interface special as compared to usual Adapters ? Usual Adapters also adapt one interface to another.
Q3) Even in the both the use cases, we see both the methods of the Extracted "Narrow Interface" GetChildren(Node) and CreateGraphicNode(Node)depending on Node. Node is an internal to Toolkit. Is Node same as GraphicNode and is the parameter passed in CreateGraphicNode only for populating the states like (name, parentID, etc) of an already created Node object ?
As per the GOF (I have marked few words/sentences as bold to emphasis the content related to my Questions)
Then there are two use cases
"Narrow Interface" being made as abstract and part of the TreeDisplayClass
Narrow Interface extracted out as a separate interface and having a composition of it in the TreeDisplay class
(There is a 3rd approach of Parameterized adapter also but skipping it for simplicity, Also this 3rd one is I guess more specific to Small talk)
When we talk about the Adapter design pattern, we typically consider two preexisting APIs that we would like to integrate, but which don't match up because they were implemented at different times with different domains. An Adapter may need to do a lot of mapping from one API to the other, because neither API was designed with this sort of extensibility in mind.
But what if the Target API had been designed with future adaptations in mind? A Target API can simplify the job of future Adapters by minimizing assumptions and providing the narrowest possible interface for Adapters to implement. Note this design requires a priori planning. Unlike typical use cases for the Adapter pattern, you cannot insert a Pluggable Adapter between any two APIs. The Target API must have been designed to support pluggable adaptations.
Q1) This is what the GoF means by built-in interface adaptation: an interface is built into the Target API in order to support future adaptations.
Q2) As mentioned, this is a relatively unusual scenario for an Adapter, since the typical strength of the pattern is its ability to handle APIs that have no common design.
The GoF lists three different approaches to design a Target API for adaptation. The first two are recognizable as a couple of their Behavioral design patterns.
- Template Method
- Strategy
- Closures (what Smalltalk calls code blocks)
Q3) Without getting caught up in details of the GoF's GUI examples, the basic idea behind designing what they call a "narrow interface" is to remove as much domain specificity as possible. In Java, the starting point for a domain-agnostic API would almost certainly be the functional interfaces.
A Target API with dependencies on these interfaces should be much simpler to adapt than an API built around domain-specific methods. The former allows for creation of Pluggable Adapters, while the latter would require a more typical Adapter with heavy mapping between APIs.
这篇关于GOF中提到的可插拔适配器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！