Re: My First C# (warning - long post)

WithOUT getting into the whole procedural vs OO debate, the recent posts in
this thread really DO remind me of "highly-modularized" procedural code that was
becoming semi-common in the late 80's and 90's (before COBOL lost its
"glitter"). In several IBM mainframe shops (which is what I knew best in those
days), the use of dynamic CALL statements with sub-programs with procedure
division that "could print on a single page of laser paper" gained a certain
(good and bad) reputation. OBVIOUSLY, the same goal of "encapsulating" logic
(and reuse of existing logic) was behind this.

It may or may not have anything to do with why OO hasn't caught on with IBM
mainframers, but the "highly-modularized" approach turned out to be a VERY bad
decision for some shops that were early implementors of IBM's LE (and, yes, I
still think it is similar to .NET CLR). In early IBM LE environments, the
overhead for doing "dynamic CALL" statements in COBOL was HORRENDOUS (especially
between old and new programs). Therefore, these "highly modularized"
applications came to screaming halts in actual mainframe production
environments. No change to code, just to run-times. (FYI, this has improved in
recent years. See LE "XPLINK" for example)

This may (or may not) have anything to do with why mainframers are "hesitant" to
move to many classes with small method applications.

(Just my $.02)

--
Bill Klein
wmklein <at> ix.netcom.com
"Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:531o4vF1pgouiU1@xxxxxxxxxxxxxxxxxxxxx

"andrewmcdonagh" <andrewmcdonagh@xxxxxxxxx> wrote in message
news:1170954277.185118.185740@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Feb 8, 1:27 am, LX-i <lxi0...@xxxxxxxxxxxx> wrote:

snipped...

That's definitely what I was looking for. :) Thanks again for breaking
it down for me.

My pleasure...

(Did you look at the "second C#" post - and if so, does it look like I'm
on the right track?)

I've given it a quick scan but will need to have another look before
commenting. Might be worth while you posting an update ...but if we
can keep it in this thread, it will help keep the topic focused and
together.

The one main OO design point that you should eventually spot from
where I'm taking you, is that numerous small classes with a single
responsibility, when working together, can create a very simple but
powerful design, with lots of code reuse.

As a top of head metric, my designs tend to consist of 40% of classes
containing a single method, which is no longer than a dozen lines of
code. Another 55% would contain at most 6 methods, with the remaining
5% of classes having more than 6 methods.

The 95% classes would having methods of no more than a dozen lines
and all hold onto the **Single Responsibility Principle. The last 5%
would be 'dodgy' and need refactoring...but then lifes too short and
we do have to actually ship stuff!

Regards

Andrew
** Single Responsibility Principle - http://www.objectmentor.com/
resources/articles/srp.pdf


I can't tell you what a relief it was to read these articles :-)

For some time now I have been trying to explain that an OO approach removes
the need for source code maintenance in the traditional sense. Classes and
methods should be encapsulated and "do what they do". When change is required
it should be new interfaces or extensions and NOT an internal change to
already working code. Apart from the obvious benefit of NOT requiring
regression testing, this approach also simplifies maintaining applications. I
came to learn this by working with COM component development over a number of
years.

Most people here, coming from a procedural background where the whole point of
good coding practice is to ensure that source code is easily maintained, and
one of the reasons for using COBOL in the first place is its
"self-documenting" nature, simply thought I was crazy.

Write applications then don't change the code? Impossible!

Of course, it isn't impossible and I've been doing it for some years now. I
see it as one of the most compelling arguments for using OO.

After a number of clumsy attempts to explain myself, I simply gave up... It's
like trying to explain the concept of "red" to a person who has been blind
since birth...

I have never studied the computer science covered in these articles, but
arrived at the same conclusions just by empirical practice.

This is the first tme I have seen some of the things I know innately,
expressed in a tangible and easily assimilable form. OK, there is a heap of
new jargon and acronyms, but the pure light of the underlying principles
shines through like a beacon.

I strongly recommend any COBOL programmer who is labouring under the burden of
heavy regression testing to at least browse the first article. (I especially
liked his description of "software rot" and what causes it :-)) Here is a
direct link:

http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf

For me, the quote of the week is:

"The Open Closed Principle (OCP)

A module should be open for extension but closed for modification.

Of all the principles of object oriented design, this is the most important.
It originated
from the work of Bertrand Meyer. It means simply this: We should write our
modules
so that they can be extended, without requiring them to be modified. In other
words, we want to be able to change what the modules do, without changing the
source code of the modules."

Now, I wish I'd thought of that... :-)

Pete.



.

Relevant Pages

  • Re: question about component integration or assembly
    ... File Design and File Indexing ... Microcomputer Applications by Graurer and Sugrue p. 370, ... management system also provides the ability to delete records as well as add ... Programmers and database users also find SQL to be valuable ...
    (comp.object)
  • Re: XP Requirement Analysis?
    ... When an existing design needs to be encoded via TDD, ... could have generated the TDD principle. ... The interface _does_ come first. ... to buy a business value. ...
    (comp.object)
  • 4th. International Signal Processing Conference
    ... "Workshop on Embedded Signal Processing and Communications System ... "Hardware Design Flows Using Model-Based Design" ... DSP and micro-controllers. ... applications for signal processing. ...
    (comp.dsp)
  • Re: My First C# (warning - long post)
    ... The one main OO design point that you should eventually spot from ... and all hold onto the **Single Responsibility Principle. ... the need for source code maintenance in the traditional sense. ... so that they can be extended, without requiring them to be modified. ...
    (comp.lang.cobol)
  • re: PL/1 professionals wanted
    ... More than 22 years data processing experience with emphasis on analysis, design, ... programming, ... and successful installation of new online and batch applications ... Responsibilities included gathering and analyzing information from users, ...
    (comp.lang.pl1)