[om-list] pattern conversions

Tom and other Packers TomP at Burgoyne.Com
Mon Sep 10 09:58:52 EDT 2001


Luke

    You are right on target.  We at TF do have a big problem organising our
code, e.g. abstracting out the commonalties in our utilities, and in
abstracting out such things as what you describe below.  I've been wanting
to do my part in motivating TF to change, and one of our programmers (Curtis
Harrison) has written just such a class.  But, I've been too lazy to use his
code in my programming (the NIH syndrome, perhaps), and there are so many
other things I'd like to change, (as explained in my last letter), that I've
been ignoring this file format issue, and will so until/unless it is also an
issue in my new shell-based design -- which it very well may be.  Thanks for
the suggestion.

    Here's a question for the whole OM group:  (I hope Ben Oman has signed
up already.  He's interested in helping us, especially in our web design.):

    How much help could I ask from the OM group in writing my shell-based
time-series data analysis system?

tomp

----- Original Message -----
From: "Luke Call" <lacall at onemodel.org>
To: "Mark Butler" <butlerm at middle.net>
Cc: "Tom and other Packers" <TomP at burgoyne.com>; "Chris Angell"
<christoph at middle.net>; "One Model List" <om-list at onemodel.org>
Sent: Monday, September 10, 2001 7:09 AM
Subject: Re: [om-list] pattern conversions


I may be out of line here due to my lack of knowledge of what
thoughtform's software does, but it also seems to me that if you have to
change many utilities each time a file format changes, you haven't
abstracted well or organized the code properly. In OO, only one class
should care about how the file is formatted, and all others should
read/write via that class. Then if the file format changes, hopefully
the api of this class can stay relatively static but its internals
change, and other classes just keep on using the same api as before. To
create such abstractions and organize code, Craig Larman's book on UML
and Patterns (I forget the exact title) is one useful reference but
there are many others. The concept however is independent of UML or
patterns--he just happens to explain things like that there (if I
remember right).

Forgive me if I am way off due to misunderstanding here....
Luke


_______________________________________________
om-list mailing list
om-list at onemodel.org
http://www.pairlist.net/mailman/listinfo/om-list






More information about the om-list mailing list