Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
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).
> 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.
> 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?
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.