-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,680
  • 22
  • 30
Vitor Silva
  • 11

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.

Jay Velasco
  • 79
  • 2
  • Hi Jay, the config is saved in DB, on runtime the system decides the destination. Each destination has its own class, the client doesnt really know who's the destination sw, it just calls IConvertSW.methodA and passes an object, in this case a Datatable with data. In the end the method returns a list of objects with the conversion result. – Vitor Silva Apr 23 '18 at 10:50
  • So in pursuit of better maintainable architetcure, i'm been running some tests with strategy pattern, this way i can develop a bunch of strategies based on the pair sw1/datatype, but if i implement with some hirearchy, i can decouple the datatype selection and destination selection. Although the concrete implementation has to be kept apart it is not strong coupled... Plz leave your comments – Vitor Silva Apr 30 '18 at 14:17
  • Under the hood you still have the same problem. The classes you are using at runtime will have the same signature... if parameter changes, then everything needs to be updated. The parameter you are passing - can you make it an object? That way you can keep adding properties to the object and use them as needed in the concrete class. – Jay Velasco May 03 '18 at 02:05
  • I got you! That way i only need an interface with some method doConvert() that each class implements and no need to be worried with the difrent properties. Thanks – Vitor Silva May 07 '18 at 12:10