-1

There's a 1st sofwtare (s1) that generates data and then there's one or more software's (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 convertion that's depends on the destination (s2 or s3) of the data. The objective is to support a wide range of destination software's. 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 be even dificult and complex. Is there any other aproach that makes it easir to implement or mantain, as separate parts as possible? what am i missing?

PS: I inhereted the current api, but i'm trying to convince my coleagues to refactir it, and i need some arguments, best examples,

Thank you for your help!

What I have tried:

So far i used interfaces, wich derived the converter of (s1 or s2), with an instance factory that returns the correct instance of the current configuration. Overal with seems to do the trick, but its not easy to maintain the diferent actions(object data type) as it needs a method for each object type convertion , 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 aplies it. This seems rather workfull to maintain in the future.

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.

| improve this answer | |
  • 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 3 '18 at 2: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 7 '18 at 12:10

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.