Talk:Adapter pattern

UML incorrect?

The Object Adaptor UML looks incorrect to me. Adapter is shown as being derived from Adaptee which is not the case in the GoF book or in the sample Java code. Maybe I'm just misreading the UML, but since the arrow comes from the top and points up into the bottom of the Adaptee box I'm assuming that means inheritance.

--ScottJ 23:21, 24 February 2006 (UTC)

The arrow from Adapter to Adaptee is not inheritance. its means interaction( i guess specifically its an assocation from Adapter to Adaptee as Adaptee is an attribute of Adapter). To depict inheritance, one of the arrow end should be triangle(as shown in Class Adapter).

--User: SsnEig Mar8 2006

Consistency in naming

Adaptor or adapter? I know both are acceptable spellings but there's no rhyme or reason to the change in spelling within the article.

Also how do you change to where searching for "adaptor pattern" to where it comes to this page?--Michael miceli (talk) 15:12, 3 April 2008 (UTC)

Term "adaptor" is used in the last two figures whereas everywhere in the text and the first figure uses "adapter". I agree that we need to use only only term.

I propose that we keep adapter as it's more commonly used. LakirKaFakir (talk) 14:41, 9 November 2021 (UTC)

Two names, one code ?

The two code samples are identical, although the text makes it seem that they should be different...

--Médinoc, 2006-08-29 21:31(UTC)

The code does not do a good job of differentiating between class and object adapters. Pkpkpkpk 18:41, 7 September 2006 (UTC)

I disagree. The two code samples are NOT identical. The first one wraps an object (namely private DList _dlist) The second one extends the DoubleLinkedList and in the same time implements stack (so one could say somehow multiple inheritance)
Hvu63 10:31, 13 October 2006 (UTC)

I agree that the code examples are poor. —Doug Bell ^talk 21:32, 5 December 2006 (UTC)

Gotta agree with the naysayers here -- the code examples don't seem to be the best. I also think the way Wikipedia is formatting the code is bad. Why do long lines not break at the right hand margin? Ugly. Anyone want to try to fix that? I'll dig out GoF and see if I can find a better example too. --Markspace (talk) 00:49, 4 August 2009 (UTC)

Here's my idea what a better example for Java should look like: Markspace (talk) 01:23, 4 August 2009 (UTC)

package wikipediaadapter;
public class AdapterDemo {
    static interface Animal {
        void makeNoise();
        void move( double meters );
    }
    /* Horse is an animal but doesn't extend the
     * interface Animal. */
    static class Horse {
        void neigh() {
            System.out.println( "neigh!" );
        }
        void gallop( int inches ) {
            System.out.println( "Galloping "+
                    inches+" inches." );
        }
    }
    /* Adapts Horse to the Animal interface */
    static class HorseAdapter implements Animal {
        Horse horse;
        public HorseAdapter( Horse h ) {
            horse = h;
        }
        public void makeNoise() {
            horse.neigh();
        }
        public void move( double meters ) {
            horse.gallop( (int)(meters * 39.37) );
        }
    }
    public static void main(String[] args) {
        Animal animal = new HorseAdapter( new Horse() );
        animal.makeNoise();
        animal.move( 1.0 );  // 1 meter
    }
}
// Output:
// neigh!
// Galloping 39 inches.

-- Markspace (talk) 01:23, 4 August 2009 (UTC)

Here's what I would use -- even shorter and sweeter and without arbitrariness:

public interface Stack {
    public void push(Object o);
    public Object pop();
}

public class LinkedList {
    public void addHead(Object o) { ... }
    public Object removeHead() { ... }
    ...
}

public class LinkedListAdaptor implements Stack {
    private LinkedList list = new LinkedList();

    public void push(Object o) {
        list.addHead(o);
    }

    public Objecct pop() {
        return list.removeHead();
    }
}

I also believe only one language is required to demonstrate a design pattern, as syntax is irrelevant. Cutting out the unnecessary keywords (i.e. visibility keywords) and calling it psuedocode could be recommended. OrangeDog (talk • edits) 01:52, 4 August 2009 (UTC)

I don't know, I think your example is a little too short and sweet. The visibility modifiers show which parts are externally visible and which parts are implementation. They're part of the pattern. Also you've cut out the driver (public static void main...) which shows how the pattern actually works. Your choice of class names and function may be better, but I think you've cut it down too much. -- Markspace (talk) 20:32, 15 September 2009 (UTC)

This isn't supposed t be a how-to guide, or a code repository, it's an encyclopaedia. Getting it as short and uncluttered as possible is the goal, which also makes it easier to verify. OrangeDog (talk • edits) 20:54, 15 September 2009 (UTC)

The subject matter of the LinkedListAdaptor is likely to be more familiar to readers. The example should be short, but no shorter than required. In particular, a main method showing the usage is certainly warranted. JMatthews (talk) 00:16, 16 September 2009 (UTC)

Clear wording

if multiple boolean values are stored as a single integer - if this means e.g. a bit vector, the description should mention it. 202.175.118.194 09:29, 28 June 2007 (UTC) Vs

Reference proposal

Here's a link I'd like to propose for this page (but as I am its author, I'm not sure whether I should put it up myself): The Adapter Pattern, DrDobb's Journal, May 8 2007

DDJ usually has nice articles, but I think that one is full of confusing (to me) technicalities. 202.175.118.194 09:33, 28 June 2007 (UTC) Vs

Agreed with the last comment - the DDJ article doesn't present the adapter pattern, it presents a particular implementation of this pattern together with some other techniques in order to achieve a clearly defined goal. I don't think it fits as a reference to this article, unless one creates a "known implementation" section - which is, IMHO, something to not do. Emmanuel Deloget 10:20, 17 July 2007 (UTC)

Conflict

In the article it says " Class Adapter pattern cannot be used in languages such as Java that do not support multiple inheritance." but the code sample a few lines below is in Java.

You forgot the first part of the sentence: "Note that when the adapter must adapt multiple adaptees". The Java code presents a case where the adapter adapts the DList class to the Stack interface. Emmanuel Deloget 21:00, 30 July 2007 (UTC)

Multiple Inheritance

The article is wrong. Java does support multiple-inheritance of interfaces, so it's no problem to implement the adapter pattern in Java. Java doesn't support multiple-inheritance of base classes, which is irrelevant to the discussion here.

One can use an adaptor to effectively inherit from multiple classes in Java though. OrangeDog (talk) 01:06, 28 November 2008 (UTC)

Odd example under Class Adapter

There's an unmarked section under the Class Adapter definition that explains a process of creating multiple Adapters for converting one value into several others, however I think that this is a far too large / extensive example, and very much aimed at one particular situation - i.e. converting one string value to several other output formats. I believe that this example should either be simplified greatly or removed altogether, or be put in an external link as an example application of the Adapter pattern.

At the very least, I'd like to see the two samples be moved between the example and the two Adapter definitions. 194.109.198.213 (talk) 13:19, 3 March 2009 (UTC)

I agree, combining Factory and Adapter and presenting as a new flavour is not necessary. Morsecode10MM (talk) 15:46, 27 March 2012 (UTC)

Commenting comments in code

I just commented the comments in the java code. Maybe I'm just a syntax-NAZI, but it felt wrong to have non-code not commented in the code box. Feel free to revert if you feel that was inappropriate of me. PrometheeFeu (talk) —Preceding undated comment added 21:00, 6 August 2009 (UTC).

Adding Spam links

Some people are adding spam links. e.g:*Citations from CiteSeer , which is in no way related to adapter pattern. I removed it.

UML class diagram for the Adapter design pattern.

I have shared the following UML diagrams I have published on Design Patterns Open Online Learning. Your comments are welcomed.

A sample UML class diagram for the Adapter design pattern.

In the above UML class diagram, the Client class that requires (depends on) a Target interface can not reuse the Adaptee class directly because its interface doesn't conform to the Target interface. Instead, the Client works through an Adapter that implements the Target interface in terms of Adaptee:

The Object Adapter implements the Target interface by delegating to an Adaptee object at run-time (adaptee.specificOperation()).

The Class Adapter implements the Target interface by inheriting from an Adaptee class at compile-time (specificOperation()).
Vanderjoe (talk) 17:53, 28 August 2017 (UTC)

Invalid Ruby

The Ruby example in this article isn't valid syntax. There is no abstract keyword or method, and there is no note that a third party library or framework is in use to implement the abstract interfaces, i.e. the Python example using @abstractmethod decorators from abc. Sj26 (talk) 06:04, 6 June 2018 (UTC)