Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
netikras1661921dI 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].
Just because a construct is an example of a pattern, doesn't mean it has been to be called FooPattern.
Adapters, Facades, Proxies - they're all just wrappers around some other stuff, presenting an interface that you want.
I honestly feel design pattern language is carried too far. The patterns themselves are an eclectic mix of structural ideas, use-cases, and work-arounds for limitations in Java.
> 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.
@VaderNT I admit, I was using ''pattern" as a short hand for the GoF patterns. In my defense, almost everyone else does too.
But 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.
But people do, in fact, fret the details.
> 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?
@VaderNT As an example, I have some code that requires an object that presents a Widget interface. Some other code FancyLib has a Foo and a Bar that provide similar functionality.
I could just write a FancyWidget that wraps the Foo and the Bar. I don't need to call it a FancyWidgetAdaptor, or a FooBarFacade, etc. If it helps to call it a BlahAdaptor, go nuts. But just pick what works in the code base and across the developers and users of the code.
It's not a particularly radical stance :)
@VaderNT On the Javariness front, things like Singleton have much simpler (in many cases) implementations in C++; Visitor is a sop to the lack of multiple dispatch in both Java and C++, though there exist other ways of doing it in C++ which may be less invasive.
IIRC (though I probably don't) there is at least one pattern which is required only because Java does not support multiple inheritance.
And so on.
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.