Re: Layers, objects, and granularity



"James J. Gavan" <jgavandeletethis@xxxxxxx> wrote in message
news:jBwOk.292$Dm5.179@xxxxxxxxxxxxxxx
Pete Dashwood wrote:
<snip>>
So COBOL-wise you are promoting small methods, correct ?


As I rarely write COBOL these days, I'm not "promoting" anything COBOL
related.

I do believe that objects and their behaviours in ANY language should be
small wherever possible.

Did you for some $12 get a second-hand copy
of Arranga/Coyle from amazon - most of their methods are no more than a
few lines of code.


Most of mine are not either. In C#, Java or COBOL. (And even in the
occasional VBScript or JavaScript).

Am I wrong, or am I wrong ? :-

You are wrong on two counts:

1. The sentence above has the qualifier MOST at the start of it. It doesn't
say this is ALWAYS the case. There are exceptions (this is one of them
because this Method is generalised code and has to deal with a number of
different possibilities. Originally each of the sections was a separate
method but, using the primitive SQL available in COBOL, I could find no way
to share a cursor across different methods, so it had to be handled in ONE
method. However, each of the functions within that method is in a section
and the sections are small.

2. I never signed a contract with Arranga, Coyle or you that said I would
abide by what you consider to be good practice.

I said I agreed with the principle and GENERALLY applied it, having come to
the same conclusion many years ago.

But most importantly, why would I apply your black and white judgements to
something that requires subtlety and consideration?

The code requires more than one section so it got more than one section. Get
over it.

IDENTIFICATION DIVISION.
METHOD-ID. HandleDB AS "HandleDB".
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.

*** Nearly missed that - can you use W/S in Methods with Fujitsu ?.

Does it matter?

As there is a WS section coded and it has entries in it, and given that the
code works, I should have thought the answer to your question is axiomatic.




01 saved-SQLSTATE pic x(5).
01 saved-SQLMSG pic x(512).
LINKAGE SECTION.
01 DBaction pic x(8).
PROCEDURE DIVISION using DBAction.
MAIN SECTION.
P001.
if DBaction NOT = 'init'
move MOST-instance-stamp to HV-DB
EXEC SQL
SET CONNECTION :HV-DB *> ensure we are using the right
connection...
END-EXEC
move SQLSTATE to MOST-SQLSTATE
MOVE SQLMSG to MOST-SQLMSG
if SQLSTATE NOT = '00000'
go to p001-end
end-if
end-if

evaluate DBaction
when 'init '
perform SQLInit
when 'start '
perform SQLStart etc...
.....................
when 'delete '
perform SQLDelete
when other
move '99999' to SQLSTATE
move 'Invalid action passed to HandleDB...' to SQLMsg
end-evaluate
if SQLSTATE = '00000'
move space to DBaction
end-if
.
p001-end.
exit method.
*---------------------------------------------------
SQLInit section.
si001.
*
* Get a DB connection...
*
* CONNECT TO DATABASE ON %DBDSN% SERVER
move MOST-instance-stamp to HV-DB *> uniquely identify
connection for
this stream
EXEC SQL
* DSN, User and password must be set in the ODBC info file
* which is external to the MOST handler.
CONNECT TO 'TestDB' AS :HV-DB
END-EXEC
* CHECK CONNECTION RESULT
IF SQLSTATE = "00000"
move "Connection to %DBDSN% server through ODBC OK..."
to SQLMsg
Log-Message
else
move SQLMsg to Log-message
END-IF
move SQLSTATE to MOST-SQLSTATE
MOVE SQLMSG to MOST-SQLMSG
invoke SELF "LogIt"
end-invoke
.
si999.
exit.
*---------------------------------------------------
SQLStart section.
ss001.

...and so on...

You can see the factory instance stamp provides a unique DB connection
identifier.

That sure looks like a *B-I-G* Method to me - you've shown TWO Sections in
the same method and presumably there are more to follow, flowing from your
Evaluates - just how many pages of paper will this 'small' method need to
print ?

As I stopped printing program code some years ago, I have no idea.

Each of the sections is small and I already explained why the Method NEEDS
to accommodate all the possible actions.

The code works. What's your problem exactly?

I do note in passing that you made no comment on what the code was
demonstrating, so obviously your priority is to try and make an issue about
something that is not an issue.


Summing up:

Over the years we've had fierce debates here about the merits of OO as
opposed to Procedural programming. While a few of us were persuaded that
OO was important, there wasn't a background of experience with classes
and objects across different environments to be able to grasp the essence
of it and explain it succinctly. People here are now are starting to
realise that the future belongs to objects. Why this is so, I have tried
to lay out above.

And it will continue to be debated. Many of course are just sweating
retirement. One can talk concepts or theory until you are blue in the
face. You'll get your chance to shoot back - wait for 'Last Hurrah - OO
Factory'.

Oh, I can't wait. Be still my beating heart...

Hopefully I've included sufficient comment in the code to guide the
uninitiated readers, just a little.

I have no intention of "shooting" at anybody. It strikes me as sad that you
see the need to.
<snipped>

Pete.
--
"I used to write COBOL...now I can do anything."



.