| Peter E. C. Dashwood 2004-06-26, 3:55 am |
| Richard,
I found this to be an interesting post.
I like your description of specific processes being abstracted and
generalised so that you can produce reports and do file maintenance
very quickly.
It is my belief that imaginative approaches like this make the
difference.
Yet, I have encountered resistance to them on some installations.
Usually, it is because if things get too easy and Users start doing
it, it could threaten programmers jobs. (Someone actually said this to
me on a site in Germany many years ago...) There is often resentment
by management also that a generalised solution may take slightly
longer (they never think about the time it will save in the future...)
Your comments regarding baggage and OO are very much in line with my
own response in this thread (I read your mail after I posted it).
Everything has to be balanced and I endorse your final statement 100%.
Pete.
(TOP post, nothing below...)
Riplin@Azonic.co.nz (Richard) wrote in message news:<217e491a.0406251250.67ada577@posting.google.com>...
> Joe Zitzelberger <joe_zitzelberger@nospam.com> wrote
>
>
>
>
> There are other ways of doing this too. For example database 'views'
> or not using '*' in the selects but specifying every field that is
> needed. Of course if the change is something that the program needs
> to deal with then it will be recompiled because it has changed.
>
> With systems using ISAM data files I always have generous fillers as
> space that can be used for data items later without worrying about
> programs that won't be concerned with it. Actually, a couple of
> decades ago, I adopted a set of 'standard' layouts that used the
> pre-defined fields as required and left room for expansion.
>
> So while you are quite correct that recompiling and retesting whole
> systems is a complete pain, there have been ways of avoiding most of
> this, or at least making it much less frequent.
>
> I have also used an interfacing mechanism, much as you describe, to
> allow a single file maintenance program and a single reporting program
> to work on almost any data file. These were initially written for CIS
> Cobol on CP/M and another 8bit system. The reporting program reads a
> script text that specifies the file, the selection criteria,
> calculations, output format. It calls interfaces for the specific
> file(s) and has a dictionary to relate the names to the actual field
> positions.
>
> The file maintenance program also uses the same interfaces and
> dictionary but also has a text 'screens layout' that specify how the
> several subscreens for each file should look plus editing criteria.
>
> If I had OO Cobol 20 odd years ago it would have been done using it,
> and would have been better for that. But the OO approach does not need
> special syntax.
>
>
> Actually Cobol's 'collection structure' is the file, and the file
> mechanisms are much richer than any other language. Much of other
> language emphasis on trees, lists, and other collections are because
> they can't easily do it with files. Given that in most cases the data
> to be put into these structures comes from files in the first place
> they should be (in general) held in that structure in the file.
>
> Granted that Cobol tables are not extensible, but they can be used to
> build any complex structure by providing index (or subscript) entries
> in the table for navigation or chaining.
>
> There _are_ things which can be done using OO which are much more
> difficult without, for example replication. For the reporting program
> (above) it has to use specific interface routines for the primary and
> secondary files, with OO I would use several instances of the same
> file objects saving some duplication of code and making it more
> extensible, and probably allowing more flexibility in systems design.
>
> But here is the problem: I have a system developed over more than two
> decades which has allowed me to put together the basis of completely
> new systems in just a couple of w s and allows me to write many new
> user requested reports in just a few minutes (in fact some users write
> their own scripts or use a generator that I wrote).
>
> The benefits of OO don't outweigh the cost of redeveloping all that I
> have done, mainly because I have much of the benefits already
> implemented.
>
> Certainly I do use OO in other languages, mainly Python, which I have
> been using for several years, but there was no existing baggage to
> overcome.
>
> In the case of the example where a small change in one file does
> require a complete rebuild and retest then certainly this would not be
> the case if it had been OO. The cost of a complete rewrite would be
> higher than the costs associated with this problem. It is only
> feasible to 'go OO' if a redevelopment is required anyway, you can't
> just add a bit of OO here and there and expect benefits immediately.
>
> It's about the cost/benefit equation.
|