OO, Modular, and related topics
From: William M. Klein (wmklein_at_nospam.netcom.com)
Date: 06/25/04
- Next message: Clark F. Morris, Jr.: "Testing and OO was Re: Is it possible to use the value of the PROGRAM ID within the source code?"
- Previous message: Donald Tees: "Re: Is it possible to use the value of the PROGRAM ID within the source code?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 25 Jun 2004 17:12:29 GMT
Just thought I would start one of my "new threads".
The intent of this note is NOT to try to "justify" (much less OBJECT TO) OO
programming or design. However, I did think that I would make a few comments on
what I think is people talking "apples and oranges".
1) *EITHER* properly designed and implemented "modular" programming and OO
programming can alleviate the need for "extensive testing everything" every time
there is a change. Although OO (and components - not the same thing - I will
happily admit) stresses "interfaces" - really the same thing is available in
traditional "modular" programming. It is just as "bad" a thing to do - to change
the "parameters" for an existing "commonly used" module as it is to CHANGE the
interface to a class/object. If the interface/parameters don't change, then
there should NOT be a need to "re-test" a properly object/module. On the other
hand "system testing" is a reasonable thing to do (and expect) for either type
of environment.
NOTE WELL:
The 2002 ISO Standard provides a "portable" (well-defined) way to do
parameter checking at compile-time for modular as well as OO applications.
2) When I first was introduced to OO programming (during the initial designs of
both the Micro Focus implementation and the ANSI/ISO COBOL design phase), one of
the major REASONS for OO "design/programming" was that it "better modeled" the
"real world. This is something that (to me) gets lost easily in "Implementation
issues" (both of compilers and applications). Modular (and structured)
programming seems (to me) to reflect a "logical" view of business (or whatever)
issues. While OO (and component) programming/design better reflects the
"physical" view of businesses. Neither of these are "absolutes" and I am not
(personally) totally convinced that one of these is always the best way to
design/implement a business solution. Whatever else one can say about these
approaches is that EITHER can be used for batch *and* online/real-time
applications.
3) It is "equally" possible (easy?) to ABUSE "modular" and "OO" programming (and
design). It is equally required that one have appropriate "tools" to do either
type of implementation. It is equally true that programmers (and analysts) need
adequate "training" (and/or experience) to do either well.
4) It seems to me that "new" (state-of-the-art) tools, databases,
recently-graduated entry-level programmers, etc all have BETTER (more extensive)
experience/training/facilities for OO (and components) than they do for modular
environments. The same can be said about "off-the-shelf" business applications
and their site-specific tailoring tools. Therefore, it seems (still to me) that
"moving to" an OO and/or component environment is a GOOD business decision. On
the other hand, continuing the internal support and expertise to exploit
existing applications seems not just a "good idea" but a requirement to keep
competitive.
***
As usual, YMMV <G>
-- Bill Klein wmklein <at> ix.netcom.com
- Next message: Clark F. Morris, Jr.: "Testing and OO was Re: Is it possible to use the value of the PROGRAM ID within the source code?"
- Previous message: Donald Tees: "Re: Is it possible to use the value of the PROGRAM ID within the source code?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
