CODEWITHSUNDEEP
javac++design-patternsparameter-passingadapter
Toan Nguyen
Toan Nguyen

Reputation: 1103

Parameterized adapters in java

I read Design Pattern of "Gang of Four" about Adapter pattern . But I read at Implementation section , paragraph 2.c talk about Pluggable adapters uses Parameterized adapters but I can't understand because example is in Smalltalk . Anyone can explain detail for me by Java or C++ ? Sorry , my english is so bad . Thanks

Upvotes: 3

Views: 460

Answers (2)

SkyWalker
SkyWalker

Reputation: 14307

Here is an additional example of the Adapter Pattern but in Java. The sample code at the bottom of that page demonstrates how to effortlessly adapt a LinkedList implementation to a Queue interface.

The example is made of the two files:

Upvotes: 0

Jerry Coffin
Jerry Coffin

Reputation: 490178

First, I feel obliged to urge a little caution against getting too deeply into use of patterns, especially in C++ (many C++ programmers have come to view emphasis on design patterns with a degree of skepticism).

That said, I doubt most people using C++ would use the approach discussed in the book. The book discusses a mix-in type approach where you'd inherit from some abstract class that defines an interface to which you'd delegate. In their example, you'd have a TreeDisplay class written in terms of some some abstract DisplayableObject class, then you'd create some specific type of TreeDisplay via (probably multiple, hopefully private) inheritance from a DisplayableObject.

I can't quite imagine anybody writing C++ this way, except in an existing project that already used this architecture. If somebody were writing new C++ to implement this, they'd almost certainly make the TreeDisplay a template, and the DisplayableObject a template parameter.

template <class DisplayableObject> 
class TreeDisplay { 
    DisplayableObject const &root;
public:
    TreeDisplay(DisplayableObject const &d) : root(d) {}   

    display(graphic const *g);

    void build_tree(DisplayableObject const &d=root) {
        for (auto child : d.get_children) {
            add_node(d.CreateGraphicNode(this, child));
            build_tree(child);  // recursively add child's children
        }
    }
}

Then the displayable object would have something like:

class DirectoryBrowser { 
    std::vector<directory> children;       
public:
    std::vector<directory> &get_children() { return children; }

    void CreateGraphicNode(TreeDisplay *t, directory const &d) { 
        t->display(d.name);
    }
};

This certainly does not match the implementation discussed in the book, but as I said above, I can't quite imagine anybody writing C++ today in the manner the book discusses. As an aside, I doubt much of anybody would directly return a reference to the DirectoryBrowser's internal data either -- that's just a quick and dirty way to demonstrate the general idea.

As far as what all this is supposed to accomplish: mostly decoupling. The TreeDisplay knows how to display items in a tree, but doesn't need to know the details about the individual objects in the tree. Conversely, the items being displayed in the tree don't need to know anything about the display being a tree. If you chose to display those same items in a flat list instead, that would make no difference to the DirectoryBrowser (or other displayable object) at all. It simply has to know how to send a displayable version of itself back to a function when asked to do so.

In short, we've minimized the interface between the two, so either can be changed without minimal effect on the other, and it's as easy as possible to implement different varieties of either and have it work with all existing implementations of the other part.

In Java, I'd guess most programmers would probably define a DisplayableObject Interface (possibly under a different name), and use that as the "plug" point, to let the TreeDisplay interact with the objects in the tree. While Java's generics probably could be used to do this, I don't see that as being nearly as likely as the use of templates in C++ (for reasons mostly unrelated to the question at hand).

Upvotes: 2

Related Questions