2

I have been handed a very cluttered, "One Ring" object (one object to rule them all). The OR class has 40 fields. These fields map to 16 different objects (the OR has all the fields from the 16 objects concatenated together. Some of the fields are common to all objects, some are unique to individual objects [all of the 16 objects are descended from a common parent]). The OR points to a catch-all table in a denormalized SQL database. I've been asked to write an adapter for this that will take random instances of the 16 objects, map the fields from a given object to an instance of the OR, and send it on its way. Oy.

Changing the back end or the code is not an option (I tried).

As I'm sure is no surprise, this beast is a nasty thing to manage. I would love to hear some thoughts about ways to help make working with this a bit more manageable. I'm primarily concerned with code maintenance: comprehension and readability. I know whatever gets implemented will be far from perfect, because I'm basically trying to make garbage look pretty. That said, for now, I have to live with it, so I'm trying to make my side of the train wreck a little bit more livable.

user2646829
  • 23
  • 2

1 Answers1

11

This is an example of a facade pattern, which may provide some starting points for your research. I've also seen it called an anti-corruption layer.

Basically, you create your dream API, the one you would create if starting from scratch today, but implement it by making calls to the current horrible back end. Then you can slowly move calling code to your new API, and when everything is moved, you can much more easily replace the back end.

This is sort of the rock climber's approach. You get a safety in place before you make the next move.

Community
  • 1
Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479