-1

There's a 1st software module (s1) that generates data and then there's one or more software modules (s2, s3) that will receive that data (objects), based on pre configured actions that define the type of data to transmit. A middleware (api) needs to get the data from s1 and convert it to s2 or s3 structure depending on configuration. The thing is there's some validations during conversion that depends on the destination (s2 or s3) of the data. The objective is to support a wide range of destination software modules. The Adapter pattern seems to be the best way to reuse as much of code to different actions or destinations, but I'm afraid that the management of it in the future may become difficult and complex. Is there any other approach that makes it easier to implement or maintain, as separate parts as possible? What am I missing?

PS: I inherited the current API, but I'm trying to convince my colleagues to refactor it, and I need some arguments, best examples, etc.

Thank you for your help!

What I have tried:

So far I used interfaces, which derive the converter of (s1 or s2), with an instance factory that returns the correct instance of the current configuration. Overall with seems to do the trick, but it's not easy to maintain the different actions (object data type) as it needs a method for each object type conversion, in each of the number of destinations classes. Also when a parameter changes I'm forced to update the interface and every other method that applies it. This seems rather workfull to maintain in the future.

Jay Elston
  • 2,750

1 Answers1

0

Changing the parameters could be easier if you pass an object - property is added, can just reference in code vs changing signature of a method.

The configuration for destinations could be driven by database tables vs a config file (not sure if that's already in place). This way it's easy to add a new destination.

Sounds like the problem is that each destination shares the same signature (Interface), but different implementations based on type. I think having to create a new class for each destination might be necessary unless you can leverage some dynamic code or meta programming.