0

I'm working toward building out a facade for a third-party API we're using with an existing application. This API ties into an external service, and it is large and lousy for testability. I'm looking into ways of wrapping it for testing (to return prepacked results instead of actually making a call to the external service) and a bit of decoupling from the actual API implementation, but there are some potential snags that could make Facade construction nearly as large as the existing API itself. A few examples...

  • "Central" class: This class is enormous and probably has close to 200 methods in it for various service calls. I believe every call to the external service (or darn near it) goes through this class at some point, sometimes when we directly call methods within, and sometimes via convenience methods within other objects.
  • Objects: There are a LOT of objects/hierarchies that call or utilize the Central class. Some of these are just convenience methods that can be easily bypassed, but some have no real direct way of being invoked by directly calling the Central class, at least not without some fairly extensive patchwork. Most will take an instance of the Central class as an argument in the constructor or have a setter method. Sure, we could build a proxy class for the Central service, but that still leaves all of these objects still tying directly into the Central class. Putting up a Facade for all of these would be a hideously tedious timesink.

Facading the Central class is fairly simple. A decorator extending and wrapping the Central class with a few additional methods can handle that, although I'm not sure if this really has any advantages beyond extending the Central class directly. This will allow us to pass an instance to the other Objects so that all calls will utilize the decorated class as well. However, this still leaves us tied pretty directly to the implementation. I'd like to decouple it further, but that would likely mean a massive amount of work to put up a Facade for 100+ classes, some of which are created behind the scenes, and a good number of which we have to create in our code for saving to the external service. We do have the source for this API, but I'm hesitant to do any major modifications as we may need to upgrade to a later version down the road.

Any tips on making this as painless as possible, or am I doomed to either accepting a partial solution or spending very large quantities of time on this? I haven't had opportunity to create a Facade this large before and it's a bit daunting. Yes, we could use a Mock framework of some sort for testing, but that's only a partial solution to address testing, not long-term support and flexibility.

user1017413
  • 2,023
  • 4
  • 26
  • 41
  • look at [mockito](https://code.google.com/p/mockito/) or [powermock](https://code.google.com/p/powermock/) – BevynQ Sep 09 '13 at 23:32
  • When I am confronted by a timesink. I write a utility program to do it for me. – BevynQ Sep 09 '13 at 23:34

1 Answers1

0

You say you want to build a facade. It means you are completely free to design your facade in any way you want! I would start with your use cases and implement the interface for those only. You do not have to interface all the "over 200 methods" you mentioned.

You use the combination of all the three following patterns at once:

  • Adapter: Converts one interface to another so that it matches what the client is expecting
  • Decorator: Dynamically adds responsibility to the interface by wrapping the original code
  • Facade: Provides a simplified interface

Sorry if I understood wrongly what you had meant.

Honza Zidek
  • 9,204
  • 4
  • 72
  • 118