[squeak-dev] Proper Smalltalk lots of classes
Jimmie Houchin
jlhouchin at gmail.com
Mon Jan 3 21:53:24 UTC 2011
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
More information about the Squeak-dev
mailing list
|