Programming Design Patterns: Facade or Not?

Another guy on our team has provided me a library as a jar for his web framework. Let's call this framework "My Friend's Framework".

There's a particular class that I need from his framework. Half of the properties exposed by that class is what I really need for my own application. The other half is not needed. To retrieve the properties of this class you need to do some String manipulation. Since I will be developing my own framework on top of this class, I want to decouple as much as possible the dependency. Maybe in the future another friend of mine will develop a better framework.

So what I did is I generated a facade class for that class. My own framework accesses the properties through my facade class. If "My Friend's Framework" did change, I just have to change one facade class and the rest remains the same. In addition, the String manipulation is done inside the facade class. Also, the facade class only exposes the needed properties. So my own framework just accesses the properties as a normal getter/setter.

However, I had an argument with this guy. He is forcing me to use directly his class since first he 开发者_高级运维won't ever change the implementation of his class. So he tells me that writing a facade class really has no value. But I disagree.

Am I wrong? I do believe I'm right though.

You are not wrong in principle.

You are wrong in that what you are doing is not a facade. Facade is more commonly used in the case where you have an API with a bunch of services. You could use all those services together, but that can get complicated. The pattern is to stand up a single API interface, the facade, which coordinates the service calls into usable, logical actions.

What you are doing is more like the Adaptor pattern. You are adapting his class to your use case by putting another class in front of it.

Note, I am merely pointing out a semantic problem, in practice what you are doing is a good design practice.

Also note that if you don't really plan on intending on updating in the future, you might not need to go thru the trouble. Maybe YAGNI -- you ain't gonna need it.

Sounds like a good design to me.

Facades typically provide an interface to a larger subsystem of classes, but I don't see why you can't also use a facade to access one complex class.

It sounds like the other person might be stubborn - so I think it is good to decouple from his framework.

If your facade is easier to use maybe you could get him to add this to his framework to provide it to everyone else too.

Your approach sounds good to me.

Just make sure you create a interface that is very independent from the actual implementation of the WHOLE framework. Some others have pointed out that is an Adapter, only because you are trying to decouple a single class, but I suspect that class is coupled with others.

Try to answer the question: What secrets should this facade hide ? Try to post some of the methods you want to expose so we can discuss.