On 1/3/2011 10:05 AM, Louis LaBrunda wrote:
Hi Jimmie,
I implemented part of the FIX protocol as part of one of my projects a while ago. I made very few classes. The fields mostly map to simple Smalltalk classes like strings, ints, decimals, data and times. Some fields are compound fields in that they contain other fields and are repeated in groups.
I did not make a class for each FIX message. I used dictionaries to map what fields were expected in each FIX message. I mapped the FIX number based field names to symbols that I made up that made sense to me and matched the FIX name for the field. This made for fairly simple code to parse/print FIX messages to and from my FIX message class. The data is stored in dictionaries with my symbols as keys and the Smalltalk value of the FIX field as the value in the dictionary.
This may not seem like good Smalltalk practice but I found that I wasn't really interested in doing anything with the FIX classes other than reading in FIX messages (data) and sending out FIX messages. For working with the data, I had other classes the matched what the system was doing. This often involved getting/sending much of the same data to/from another system that had its own message format.
In that case I have basically the same data in a whole bunch of classes that match say a non FIX message format and an equal number of classes that match the FIX format. Which one should you use to work with the data within the system? So, on both sides I have simple classes that basically just move the field data to and from dictionaries by parsing or printing the values in the correct format.
This made for some less than pretty code like:
asc := msg at: #AccountSourceCode.
instead of:
asc := msg accountSourceCode.
but it allowed for moving large numbers of fields from one message format to another with a loop that ran a dictionary that had matching symbolic field names for each message format.
orderedCollectionOfFieldsToCopy do: [:f | | fixSymbol | fixSymbol := dictionaryOfCorrespondingFields at: f. fixMessage at: f put: (nonFixData at: fixSymbol). ].
Again, I don't know if this is in the best tradition of Smalltalk but in my multi message format environment, it seemed best.
Lou
Hello Lou,
I don't think any of that sounds unreasonable. I just knew I wasn't wanting to create 1100 classes for the field types and the message types. I have been looking at the field types in the documentation and it looked reasonable to do exactly what you said, and I had planned on doing similarly. But I hadn't quite gotten to looking at doing similarly for the message types. I will take a look at that. The more that I can automate, the faster I can get it working and spend my time on more interesting problems. And like you say it is easier to add or move to other versions. I know my current need is for version 4.4. But I don't what other brokers or other the future requirements will be. It is nice be agile.
I think this is somewhat the simplest thing that could possibly work. If performance is insufficient or any optimization is required, it could then be done on a message by message, or field by field basis and still maintain a working system.
Thanks for sharing your experience and advise.
Jimmie