On 12/31/2010 5:12 PM, Colin Putney wrote:
> On Fri, Dec 31, 2010 at 5:24 PM, Jimmie Houchin<jlhouchin at gmail.com>  wrote:
>> In the Java implementation there are over 2000 classes. In the protocol
>> there are approximately 90 message types and 956 field types.
> [snip]
>> Am I way off base here? Should I really create the 956 classes necessary to
>> for each field in addition to the 90 or so message classes, and then I don't
>> know what else I haven't discovered yet. Having 1000+ classes just seems
>> unwieldy and naively it just doesn't feel like the Smalltalk way. I could be
>> wrong, but I haven't seen such an example to my memory. I don't know enough
>> about Java to know if it is good Java form either.
> [snip]
> I'm not a Java expert, but I can sort of see the rational for having
> so many classes in a statically-typed language. You can use the type
> system to enforce the correctness of the protocol implementation. With
> a class for each type of field, you can declare variables with the
> types of fields expected by the protocol, and the compiler will tell
> you if you try to do something that doesn't fit the protocol
> specification.
>
> In a dynamic language like Smalltalk, though, I'd expect classes that
> map to the *structure* of the protocol rather than it's specification.
> Perhaps many of those 956 field types are quite similar and can be
> modelled by just a handful of classes.
>
> Another thing to look out for is opportunities to model things with
> composition instead of inheritance. The Java implementation is
> modelling the protocol largely in the type system, and as such it has
> to have single objects to which the types can be applied. Since you're
> going to be modelling the protocol with objects rather than types
> you're free to represent the elements of the protocol with clusters of
> objects. (For example, you might have a Field object that only
> represents the data in the field, and contains a reference to a
> FieldType object that describes the semantics of the field).
>
> BTW, Congratulations on taking on such a big project - good to see it
> happening in Smalltalk.
>
> Hope this helps,
>
> Colin

Hello Colin,

Thanks for the advise.

I hadn't planned on following the Java model unless specifically advised 
to here. I understand that Java and Smalltalk are very different beasts. 
But I did want to double check and inquire.

The protocol is a purely message based protocol, where you have messages 
with specific and specified fields in those messages. The messages are 
sent in text from client to server. This is why my focus has been on the 
messages and the requirements of the messages. Provided that the 
messages are well formed, the creation and verification of the fields 
making up the messages isn't as important that they be their own 
independent classes.

Most of the fields are simply strings, chars (single character strings) 
or ints. Some have a set of values from which the value is required to 
be from. I have created my Fix44Field class to be able to handle the 
values, types and the constraints on the values without requiring a 
class for each type.

This allows me to easily do a couple of roundtrips on the documentation 
and have the fields implemented. The more I can write methods to parse 
the docs and create the classes the happier I am. :)

This will also help me to be able to easily update to newer versions.
I really wanted to make sure I wasn't making any radical mistakes.

Doing this protocol helps me get away from having to interface a COM 
library or use a Java library. It will also allow me to migrate away 
from Windows in the future. :)

Hopefully as I implement a viable tool to implement trading strategies, 
it becomes an attractive option for people who want to create their own 
strategies but not have to program the entire application. It would be 
nice to have a small community grow around this over time. It is my 
privilege to contribute something back to the community I receive so 
much from.

Thanks for your help.

Jimmie