We Keep Coding

Pluggable Adapter as mentioned in the GOF

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)
ObjectWorks\Smalltalk [Par90] uses the term
pluggable adapter to describe classes with built-in interface adaptation.
Consider a TreeDisplay widget that can display tree structures graphically.
If this were a special-purpose widget for use in just one application, then
we might require the objects that it displays to have a specific interface;
that is, all must descend from a Tree abstract class. But if we wanted to
make TreeDisplay more reusable (say we wanted to make it part of a toolkit
of useful widgets), then that requirement would be unreasonable.
Applications will define their own classes for tree structures. They
shouldn't be forced to use our Tree abstract class. Different tree
structures will have different interfaces.
Pluggable adapters. Let's look at three ways to implement pluggable adapters
for the TreeDisplay widget described earlier, which can lay out and display
a hierarchical structure automatically.
The first step, which is common to all three of the implementations discussed
here, is to find a "narrow" interface for Adaptee, that is, the smallest
subset of operations that lets us do the adaptation. A narrow interface
consisting of only a couple of operations is easier to adapt than an
interface with dozens of operations. For TreeDisplay, the adaptee is any
hierarchical structure. A minimalist interface might include two
operations, one that defines how to present a node in the hierarchical
structure graphically, and another that retrieves the node's children.
Then there are two use cases
"Narrow Interface" being made as abstract and part of the TreeDisplay
Class
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.

Let me share a couple of thoughts.
First, since the question has been posted with the Smalltalk tag, I'll use the Smalltalk syntax which is less verbose (e.g. #children instead of GetChildren(Tree,Node), etc.)
As an introduction to this issue (which may be useful for some readers), let's say that (generic) frameworks need to use a generic language (e.g. #children). However, generic terms may not be natural for the specific object you are considering. For example, in the case of a File System, one usually has #files, #directories, etc., but may not have the selector #children. Even if adding these selectors won't kill anyone, you don't want to populate your classes with new "generic" selectors every time an "abstract" class imposes its naming conventions. In the real life, if you do that, sooner or later you will end-up having collisions with other frameworks for which the very same selector has a different meaning. This implies that every framework has the potential of producing some impedance (a.k.a. friction) with the objects that try to benefit from it. Well, adapters are meant to mitigate these side effects.
There are several ways to do this. One is making your framework pluggable. This means that you will not require the clients to implement specific behavior. Instead you will ask the clients to provide a selector or a block whose evaluation will produce the required behavior.
In the Directory example, if your class Directory happens to implement, say #entities, then instead of creating #children as a synonym, you will tell the appropriate class in the framework something like childrenSelector: #entities. The object receiving this method will then "plug" (remember) that it has to send you #entities when looking for children. If you don't have such a method, you still can provide the required behavior using a block that does what's needed. In our example the block would look like
childrenSelector: [self directories, self files].
(Side note: the pluggable framwork could provide a synonym #childrenBlock: so to make its interface more friendly. Alternatively, it could provide a more general selector such as childrenGetter:, etc.)
The receiver will now keep the block in its childrenGetter ivar and will evaluate it every time it needs the client's children.
Another solution one might want to consider consists in requiring the client to subclass an abstract class. This has the advantage of exposing very clearly the client's behavior. Note however than this solution has some drawbacks because, in Smalltalk, you can only inherit from one parent. So, imposing the superclass may result in an undesirable (or even unfeasible) constraint.
The other option you mention consists in adding one indirection to the previous one: instead of subclassing the main "object" you offer an abstract superclass for subclassing the behavoir your object needs to adapt. This is similar to the first approach in that you don't need to change the client, except that this time you put the adapted protocol in a class by itself. This way, instead of plugging several parameters into the framework, you put them all in an object and pass (or "plug") that object to the framework. Note that these adapting objects act as wrappers in that they know the real thing, and know how to deal with it for translating the few messages the framework needs to send. In general, the use of wrappers provides a lot of flexibility at the cost of populating your system with more classes (which entails the risk of duplicated hierarchies). Moreover, wrapping many objects might impact the performance of your system. Note by the way that GraphicNode also looks like a wrapper of the intrinsic/actual Node.
I'm not sure I've answered your question, but since you asked me to somehow expand my comment, I've happily tried so.

Q1) Interface adaptation just means adapting one interface to implement another, i.e., what adapters are for. I'm not sure what they mean by "built-in", but it sounds like a specific feature of Smalltalk, with which I'm not familiar.
Q2) A "Pluggable Adapter" is an adapter class that implements the target interface by accepting implementations for its individual methods as constructor arguments. The purpose is to allow adapters to be expressed succinctly. In all cases, this requires the target interface to be small, and it usually requires some kind of language facility for succinctly providing a computation - a lambda or delegate or similar. In Java, the facility for inline classes and functional interfaces means that a specific adapter class that accepts lambda arguments is unnecessary.
Pluggable adapters are a convenience. They are not important beyond that. However...
Q3) The quoted text isn't about pluggable adapters, and neither of the two use cases has a pluggable adapter in it. That part is about the Interface Segregation Principle, and it is important.
In the first example, TreeDisplay is subclassed. The actual adapter interface is the subset of methods in TreeDisplay that require implementation. This is less than ideal, because there is no concise definition of the interface that the adapter must implement, and the DirectoryTreeDisplay cannot simultaneously implement another similar target interface. Also such implementations tend interact with the subclass in complex ways.
In the second example, TreeDisplay comes with a TreeAccessorDelegate interface that captures the requirements for things it can display. This is a small interface that that can be easily implemented in a variety of ways, including by a pluggable adapter. (although the example DirectoryBrowser is not pluggable). Also, interface adaptation does not have to be the sole purpose of the adapter class. You see that DirectoryBrowser class implements methods that have nothing to do with tree display.
The Node type in these examples would be an empty/small interface, i.e., another adapter target, or even a generic type argument so that no adaptation is required. I think this design could be improved, actually, by making Node the only adaptation target.

Add additinal functionality to existing methods

I have a web application in Servlets and JSP. Now i need to add some additional functionalities to a couple of service methods in it. Service methods those needs these changes are from different servlets.
Additional functionalities are as follows.
Validating status before its core function.
Notify respective users on successful completion of that process.
How can I inject these functionalities to existing code with minimum overhead?
I think AOP in spring can help here, but i cant use Spring in existing application for this feature.
Also tried to use decorator pattern, but i couldn't as each service class contains multiple methods, also there is no common interface for them.
Can someone let me know how to handle this change in a better way.

Also tried to use decorator pattern, but i couldn't as each service
class contains multiple methods, also there is no common interface for
them.
As you are stating that there is no common interface, you can use Adapter Pattern which is the best fit when you have problems with service interfaces. Basically, adapters help to interact with two services with no common interface. You can create an adapter (layer) which handle the additional functionalities (i.e., Validating status and Notify respective users, etc..) by invoking the existing services.
Below is the wikipedia definition for adapter pattern:
the adapter pattern is a software design pattern (also known as
Wrapper, an alternative naming shared with the Decorator pattern) that
allows the interface of an existing class to be used as another
interface. It is often used to make existing classes work with others
without modifying their source code.

Best Practice (Design Pattern) for copying and augmenting Objects

I'm using an API providing access to a special server environment. This API has a wide range of Data objects you can retrieve from it. For Example APICar
Now I'd like to have "my own" data object (MyCar) containing all information of that data object but i'd like to either leave out some properties, augment it, or simply rename some of them.
This is because i need those data objects in a JSON driven client application. So when someone changes the API mentioned above and changes names of properties my client application will break immediatly.
My question is:
Is there a best practice or a design pattern to copy objects like this? Like when you have one Object and want to transfer it into another object of another class? I've seen something like that in eclipse called "AdapterFactory" and was wondering if it's wide used thing.
To make it more clear: I have ObjectA and i need ObjectB. ObjectA comes from the API and its class can change frequently. I need a method or an Object or a Class somewhere which is capable of turning an ObjectA into ObjectB.

I think you are looking for Design Pattern Adapter
It's really just wrapping an instance of class A in an instance of class B, to provide a different way of using it / different type.
"I think" because you mention copying issues, so it may not be as much a class/type thing as a persistence / transmission thing.
Depending on your situation you may also be interested in dynamic proxying, but that's a Java feature.

A bit of a complexity in Using the factory design pattern

As it is said "if we have a super class and n sub-classes, and based on data provided, we have to return the object of one of the sub-classes, we use a factory pattern"
Situation:
I have 20 clients, more can be added with time. Each will provide a file from which data would be extracted and inserted into the db. Every client has his own style of mainting the file i.e. data fields would be at different places.
Solution:
For this I think I will have to use factory design pattern, I create 20 classes and every class has its own implementation of every field, like how and from which place in file it has to extract it. As new clients are added, I just create a new class and I am done, no other changes are required.
Am I correct till here?
Complexity:
Now the problem is that the files that clients' provide, can be in either of the 4 formats (PDF, XLS(X), HTML, TXT). THe engine that extracts text from these formats has to be static, like I use pdftoXML to extract PDF to XML etc. If I dont create a seperate engine class that just converts the PDF to XML then I would have to re-write the functionality of PDF text extraction in every client's class that provides file in PDF. The same is the case with excel extraction engine.
Question:
How should I encorporate these engines in factory pattern? Should the engines classes be static and the sub class that has to deal with pdf for example, calls the pdf class' extract method to get the reqtuired data or what?
Hope I made myself clear, thanks

I think this is a good use of Factory Method, but don't try to use the client class hierarchy to model the extraction algorithms as well. In terms of patterns, you could use Strategy to dynamically configure a client object with the right kind of extraction algorithm.

You have (at least) two things going on here.
Extracting text from a range of file formats
Parsing this text according to client specific rules.
I would separate these functions completely. Perhaps even have two factories, one for text extraction and one for parsing. The client specific code that does the parsing, does not need to know that the text came from a PDF, CSV, or was piped in over http or whatever. It merely needs to know about parsing text.
Hope this helps.

To start with, a few questions. These may change the suggested solution:
Does each of the 20 clients have a single FileFormat?
What is common (behavior/methods) between the subclasses?
Is there ever a chance that a subclass might change such that is utilizes a different FileFormat?
In the simplest solution where subclasses do not need to switch file types, Seems like right now you could have an abstract ContentProvider which is subclassed by a set of abstract classes PdfProvider, XlsProvider, HtmlProvider, and TxtProvider. This middle layer of classes implement the file-format specific functionality. Then your 20 "client" classes inherit from the appropriate FileFormat-specific base.

Java design pattern

I am new to design pattern. I have a small project in which java classes use dummy data when not connected to server. I have if condition in class that switches between dummy data and server data depending on a flag . Is there a better way this can be implemented?

Instead of controlling your code with an 'if' statement, you should write an interface that defines all the methods you will need to interact with the server, and reference that interface instead of a concrete implementation. Then, have your 'dummy data' implement that interface.
The advantage of this is that your code will be written in a way that is not dependent upon the server implementation. This will allow you to change details on the server without changing your client's implementation.

I would recommend using the Repository pattern to encapsulate your data layer. Create an interface for the Repository and have two concrete implementations, one for dummy data and the other for server data. Use the Factory pattern to create your Repository. The Factory would return the correct concrete implementation of the Repository based on whether you are connected or not.

You need a Data Access Object, or an object which acts as a proxy between the requesting program and the data.
You ask the DAO for the data, and based on it's configuration, it responds with your server data, or other data. That other data might be newly instantiated classes, data from text files, etc.
In this image, the "Business Object" is your program, the "Data Access Object" is the reconfigurable gate-keeper, the "Transfer Object" is the object representation of the data requested, and the "Data Source" is the interface which you previously used to get to the data. Once the "Data Access Object" is in place, it is not hard to add code to it to "select" the desired data source (DummyDataSource, FileDataSource, JDBCDataSource, etc).

Proxy_pattern suits best for your use case.
In short, a proxy is a wrapper or agent object that is being called by the client to access the real serving object behind the scenes.
You can find explanation for tutorials point example here:
Proxy Design Pattern- tutorialspoint.com example
Have a look at below articles
oodesign proxy
tutorials point proxy
sourcemaking proxy example
dzone proxy example

If you want a design pattern, then State pattern is what you need.