This is my first time asking a question on StackOverflow, so please bear with me. I am working on a small team, primarily focused on developing desktop applications for industrial settings using C#. I have recently started learning about design patterns, and have been making use especially of the Factory Method and Fluent Builder interface. However, I have run into an obstacle, and I wanted to try to get some better perspective before moving forward and risking some poor coding implementation.
My problem is this - a large core of our application relies on messaging back and forth with a machine. There are 6 different messages, and each one is made up of anywhere from 1 to 20 or so different fields. I have been making use of the Fluent Builder to generate these, and so far it has worked out great. Unfortunately, we are up to the 15th revision of the message layouts. The other team members would like our application to be able to switch between any of the 15 different message layouts at will, but therein lies the daunting task. Each revision can have vastly different layouts for the 6 messages, so there is something close to 90 different total combinations (15x6), each of course with their respective 1 to 20+ individual fields.
There is not enough common similarities across all 15 revisions of each individual message type to make use of one common interface or abstract class. At the moment, I have been generating each of the 90 messages with the suffix "V##", representing the current version of that message type. For example:
// Builder Chains
public MachineStatusRequestBuilderV15 WithEquipmentID(string equipmentID)
{
this._equipmentID = equipmentID;
return this;
}
// Conversion Operator - returns the generated message
public static implicit operator MachineStatusRequestV15(MachineStatusRequestBuilderV15 builder)
{
return new MachineStatusRequestV15(builder._equipmentID);
}
I have then been creating a corresponding builder using the Fluent Interface, and pulling the whole thing together with the Factory pattern. I have intentionally omitted most of the code just due to the sheer volume of it, but I can provide additional short snippets if needed. Just from this description, does anyone have any suggestions of a more-efficient architecture to handle this type of situation?
