Giving Up on “Clever” Constructor Usage – Go Simpler
OK, I decided today to give up my clever solution to parsing these exchange messages into normalized messages. It was just too nasty. The basics seemed to work well enough, but if there were a value I wanted to set that wasn't in the exchange data feed - like which feed this was, then I had a real problem. If I used the "tag" list constructor, the value needed to be set, and the setters are protected because I want these guys to appear immutable to all the other parts of the system. So I had to make a friend relationship.
But because each of these codecs might generate any number of these normalized messages, I'd have a ton of friend statements in each class. That's just not supportable. At some point in the future, someone is going to forget to add one in, and then it's a mess as they try to figure out what's going wrong and fix it.
It's far easier to realize that each normalized message has a complete, typed, constructor, and all I need to do is to parse out the values from the exchange data stream, and then call that version of the constructor, and we're done. Nothing fancy. Not all tricky. Just plain and simple code.
While the other approach might have been nice to figure out how to skip values in the tag list, or put in functors for callbacks to the different date/time parsers for the different exchanges, it was all a bunch of mental gymnastics as it really didn't make the code any easier to read, any faster, or any more supportable. It was coder ego, and that's something I just hate to see.
So I simply cut out all the crud I'd made, and went back to a far simpler scheme, and the code looks much better for it.