I recently had to work with an SDK that had a lot of crazy parts*. Not using the SDK was not an option as it had to talk to some third party software.

What is the best way to deal with the crazy code? I genrally used static methods to convert between sensible data types to the format they required (ie bool to yesNo). That method did however lead to lots of calls to very unintuative static methods (which one of the three dateToString methods should be called where?)

Would a better approach be to store almost everything as a string in the database? Or possibly convert each datatype inline so its clear (although with repeated code). Possibly there is some more elegent solution I hadent thought of?

*Certain methods required an enum called yesNo which contained "Yes","y","No" and "n". There were also multiple diffrent formats of string they wanted to represent datetimes used inconsistently. There were also other smaller bits of crazy code.

  • 1
    It's not inconceivable that the SDK was created to help bridge the gap between good programming methods and a very fuzzy business datastore of some kind. You might want to investigate if the "craziness" was done for a particular reason because it might be necessary to replicate this craziness with your own insanity. – Joel Etherton Sep 30 '11 at 12:39
  • 1
    man, sounds like your work sucks. I do not have the names of the patterns memorized, but I would say: "Put a bag (wrapper) around it" and polish that bag until it makes your job much easier. – Job Sep 30 '11 at 15:55
  • @Job Its only one part of my work to integrate with providers and some of them know how to code :) – Tom Squires Sep 30 '11 at 15:56

This sounds like an appropriate use of the Adapter pattern. You could pass your "sane data" and make more appropriate methods calls. If you wanted to abstract away some calls to simplify the interface, rather than just transforming it, that would be an appropriate use of the Facade pattern.


If the size of the API is sufficiently small (i.e. it is either rather small or it is medium-sized, but you'll be using it for years), then you could write a proper wrapper for the API with sensible interface.

I.e. you could write the wrapper in a way that you don't need to call a single method of the original API to use it.

This approach has an additional benefit if you can make your wrapper "biased" (i.e. whenever frobnicating a foo you must frobnicate the associated bar as well) or "convert" between paradigm (for example producing an OO-wrapper around some non-OO-API).

It will involve significant effort, however, so make sure that it'll be worth the time first.

  • 2
    Most of the time you don't need the entire API. You can wrap just enough for your needs and add to it later as necessary. – Karl Bielefeldt Sep 30 '11 at 12:32
  • @KarlBielefeldt: of course, you can restrict the scope of your wrapper. You'll still have some overhead, however. – Joachim Sauer Sep 30 '11 at 12:43

Trying to do the bare minimum to convert data types is just going be more grief. Write the API as you wish they did, and implement it as a wrapper to theirs. It's a little more typing up front, but a lot less work overall.


Given the nature of the issue, I'd consider Anti Corruption Layer.

...it is likely that... you are inevitably faced with the task of interacting with the spaghetti that is already there. Enter the Anti-Corruption Layer. (Anatomy of an Anti-Corruption Layer, Part 1)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.