As I understood the Adapter pattern, you start with two given (!) interfaces that are incompatible, create a class that implements one interface, and has the second interface as a property. Then the methods of the implemented interface wrap the calls to the interface referred to from the property.
Everything is fine with that.
Now I wonder, why every other class in our code base is suffixed with "Adapter". There is some external thing to be used, like a file storage, a message queue, an email service or just something outside of the system. But the class that makes use of that external interface is made up on our own, no interface given.
So I think Adapter is a misnomer, because we do not adapt thing A to thing B, we just use thing B and call it from some class.
What are your thoughts on that?

I don't think you have to implement both interfaces in the same class.. I mean.. Use decoration to build an adapter. Why not? It still does the job - adapts A for B.

But I don't think that your case is using adapter correctly. Imo all you need is an interface for some service and an implementation of that service, using calls to 3rd party services [integration]. I see no need to adapt anything to anything here. It's just a plain simple implementation.

An adapter would be maybe if you had to make two incompatible APIs talk to one another. Like an adapter making Spring and OSGi contexts discover each other's beans [if you speak in java terms].

> As I understood the Adapter pattern, you start with two given (!) interfaces that are incompatible, create a class that implements one interface, and has the second interface as a property.

Kind of. I think there might be some confusion about what "interface" means in this context.
In the case of the adapter pattern, "interface" means "the public methods and behaviour of a given class", which is not the same as, say, the "interface" keyword in Java.

An adapter provides the interface (=methods and behaviour) the calling code expects, translating it to calls to an object with a different interface (again methods and behaviour).

Whether the adapter implements an interface (Java keyword kind) is irrelevant to the pattern. As is how the adapter holds a reference to the object (directly or using an interface definition, again the Java keyword kind).

@halfflat
> The patterns themselves are an eclectic mix of structural ideas, use-cases, and work-arounds for limitations
Yes, that's exactly what patterns are: Approaches to solutions for recurring problems. If a given language provides other solutions already or the problem doesn't exist in the first place, a pattern is unnecessary there.

> in Java.
in general.

@halfflat
> I admit, I was using ''pattern" as a short hand for the GoF patterns. In my defense, almost everyone else does too.

Sure, no need to defend yourself. I was mainly thinking of the GoF patterns, too. :) Though they aren't Java specific. They can't be, the GoF book has examples in C++ and Smalltalk.

> the key point is that there's no great underlying taxonomy of patterns - they _are_ ad hoc. Saying that _this_ is an Adaptor, and _that_ is a Facade is overstating things. We should just pick names that make sense in context, take patterns as simply useful ideas, and not fret the details.

Hmm, I don't quite understand your point. Maybe adapter and facade are too unspecific, or an example could help.
Imho patterns define a common vocabulary that I find useful. If I name a class "CustomerFactory", I communicate certain things to other devs about what the class is gonna do. Should I pick a different name that "makes sense in context"? What would that be?

@halfflat
Thanks for clearing that up, makes sense! I agree, I'd drop that "adapter" suffix there, too.

I guess we're also actually in agreement about that Java thing and I just misunderstood. Your original sentence was: "The patterns themselves are an eclectic mix of structural ideas, use-cases, and work-arounds for limitations in Java" - I read that as "The patterns are (a list of things) in Java". It dawns on me you actually meant "patterns are (a list of general things) and [some specifically are] work-arounds in Java".

That's what you meant, right? No objections to that.