Re: OO Reuse

From: Warren Simmons (wsimmons5_at_optonline.net)
Date: 05/23/04 

Date: Sun, 23 May 2004 03:39:10 GMT

James J. Gavan wrote:
> Peter E. C. Dashwood wrote:
>
>> "James J. Gavan" <jjgavan@shaw.ca> wrote in message
>> news:<jahrc.552448$Ig.270662@pd7tw2no>...
>>
>>
>>> Primarily for Daniel, who is 'thinking' about OO, but also for those
>>>
>>
>> others who use OO, the following extract from a comp thread dealing
>> with the topic REUSE. The author was saying OO Reuse was difficult for
>> several reasons, (his earlier text was more abstract/academic), but I
>> think he really hits the nail on the head with the following. For my
>> money a complete 100% endorsement. Having 'moved around a bit' on OO
>> technology, I'd bet Donald will probably agree too :-
>>
>>
>>> "...... 3. Reusable code only emerges by attempting to reuse it.
>>> Just saying
>>> "write reusable code" won't work, because it's nearly impossible to
>>> predict the needs of future projects from the experience of a single
>>> project.
>>>
>>>
>>
>> <<<
>> It's a lot more likely to get an accurate prediction of the needs of
>> future projects if you have done some, than if you have done none...
>>
>>
>>
>>> The only way to have good reusable code is to continuously refine it
>>> based on experience.
>>>
>>
>> <<< Absolutely. I have always advocated the iterative approach.
>>
>>
>>
>>> The reusable components we rely on today didn't
>>> just spring out of someone's head one day -- it's taken years for most
>>> of them to reach their present level of usability. "
>>>
>>>
>>
>> <<<
>>
>>
>
> Let's start here otherwise we are jumping all over the place for a
> definition. I'm inclined to think his definition of "components" is
> pretty generic. Sounds daft, but Thane gave the accurate answer, some
> time back, "A component is what you want it to be". That neatly
> dovetails my interpretation and yours.
>
> Now consider - if he was claiming that your type of component or GUI
> based components are subject to failure. - then there wouldn't be too
> many of them out there to buy. You pay money for something that looks
> like it does the job, if it fails, you drop the damn thing, certainly
> never deal with the vendor again, and probably also switches you off
> components completely.
> What a success story !
>
> Let's move beyond discrete reasonably defined components to some of the
> more challenging ones - Appointment Books, Treeviews etc. Particularly
> the Treeview, other than adding gizmos like images (folders, coloured
> buttons) using a combination of ON/OFF on the buttons [+] or [-] to give
> you different Treeview layouts, and perhaps adding checkboxes it's a
> fairly straight forward exercise once you've got the knowledge through
> testing methods available.
>
> Now the tricky part for a Treeview component to be salable, it must
> have the flexibility to cater for many different end-user needs. I
> don't know how universal the Treeview concept is, but would suggest,
> that other than what you see in Windows Explorer (folders/directories),
> or perhaps IDEs (sourcefiles), the Levels relate to records. The
> Treeview *MUST* allow for adding new Levels and deleting old Levels,
> (plus their subsidiaries; e.g. if you delete a Level 2 entry and there
> are Levels 3 through 7 subsidiary to the Level 2 entry.
>
> Bit complex but is achievable by thinking it through before you put pen
> to paper. (Note : That's not what I've done because from the DB Table
> structure I probably wont go below a Level 4 - however I'm not trying to
> sell components - just obtain REUSE in design - it's the overall logic
> I'm after - the domino effect where a change occurs at Level 2 - what
> impact does the Parent Level 2 record have on subsidiary levels).
>
> Again if you are going to market these - same reasoning as above -
> otherwise you finish up with a repeat of , "What a success story !".
>
> It would certainly cover the above two areas in his use of the word
> 'components', but I think he is probably addressing the area of REUSE
> through 'sub-routines' a super class addressing the needs of
> sub-classes. Now, and I thought this from day one when getting into OO,
> while necessary as an introduction, there is an awful lot of theoretical
> bull*** associated with OO.
> Warren, if you are reading this, these guys don't use $10 words like
> 'encapsulation' and 'polymorphic', they go off into the realm of $50
> words ! Plus any COBOL folks who have looked at OO will be familiar with
> "Is a ?" or "Has a ? and CRC cards. Any of you actually uses these
> techniques before writing *real* application code ?
>
> Throw a problem at any COBOLer, Procedural or OO - Task : use both COBOL
> files and DB Tables and come up with a CustomerRecord, and Transaction
> File, and somewhere you have got to hold this ancillary information :-
>
> Current Balance, Last Transaction Date, Credit Rating, Last Payment Date
> and Amount, Sales This Month, Sales Year-to-Date.
>
> Because COBOL is business-centric, any COBOLer worth his salt can come
> up with two decent sets of databases. Given ten developers take a shot,
> they will come up with a fairly close match on Customer Record or the
> Transactions. As regards those ancillary bits of information, different
> approaches, and probably each one can be justified..
>
> I had to spell out the above, because I think there is a tendency in the
> OO groups to talk at the academic/abstract level. I just recently saw
> a message where a kid for starters wanted to create a game - so he was
> asking for guidance on the Monsters, and Hits, (explosives etc.) and the
> correct OO relationship between these. Well I ask you ! Firstly son,
> give me a more detailed spec of what you want and then we can take it
> from there. Naturally he got a bunch of answers dealing in the abstract,
> and he is probably now no wiser than I am !.
>
> I've a gut feeling, this over-indulgence and devotion to
> theory/abstracts impedes on a practical system design and if they get
> their classes split, this way, that way, umpteen ways - to even attempt
> REUSE can be a nightmare. For what it is worth, my own imposed set of
> rules for REUSE and we can use a Droplist or Listbox, plus files/DB
> Tables and its associated collection as the basis :-
>
> #1 - Design DBI(Database Interface) for file # 1 - "create" collection
> with "add", "change" and"delete", plus methods to retrieve from the
> collection "getKeyFromIndex", "getIndexFromKey" - first time around so
> the code is very specific to File # 1
>
> #2 - Do the same for File # 2 - wait a minute, I've already done that
> for # 1 - so copy/paste from #1 giving #2 and change info specific to #2
>
> # 3 - Do the same for File # 3 - Hey ! I've done this twice already !.
> Never mind repeat Step #2.. But I am already thinking 'There's gotta be
> a better wary to design a mousetrap".
>
> # 4 - No way ! I've done this three times already. Let's think how we
> want to catch *any* mouse.. Not quite like String2Num, but this is a
> discrete area - creating collections, updating them and querying them.
> So instead of individual DBIs doing everything, as I explained
> previously, move collection creation and comparable methods up into a
> new super DBIMain.
> Now our sub-classes, with much code deleted can access super DBIMain.
>
> Works great - particularly when I tried it in my test application using
> three ISAMs to create Treeviews - with Level 1 - Continent, Level 2 -
> Country and Level 3 - specific cheese names. Two droplists created -
> Continent used with the Level 2 Dailog and a Country droplist used with
> the Level 3 dialog.
>
> Yes worked great until I used it with my *real* application - creating a
> Listbox from a DB Table. Went belly up ! I had forgotten that I allowed
> sequencing (1) Default - description, (2) Key and (3) Any Other data.
> Nevertheless the problem is not insurmountable. But it illustrates how
> you can goof - this of course I'm picking up at the development stage,
> not even the true testing stage.
>
> The problem is related to the fact I know what I want it to do - but I
> have logic errors in my thoughts - call me computer challenged if you
> like :-) . As opposed to self-contained components like String2Num
> there's a lot of interaction going on between different classes which I
> can't demonstrate here graphically . But taking the DB Table flaw I
> found :-
>
> Class Names
> 1 - MaterialsEdit
> 2 - MaterialslDialogParameters
> 3 - TabbedDialog (create an instance of MaterialsDialog using
> MaterialsDialogParamerters)
> 4 - DBIMain (super)
> 5 - MaterialsDBI (sub-class inherits from DBIMain)
> 6 - MaterialsTable
> 7 - SqlConnection
> 8 - SqlErrors
> 9 - ErrorMesssges (can pop up from several of the above)
>
> There is direct inter-action between 1, 3, 4, 5 and 6. At least for
> this particular human it's a little difficult acting as Stromboli
> keeping Pinnochio and all the marionettes together. If you persist,
> there certainly is a payoff .
>
>> Well that depends on the components. I have a number of reusable
>> components that did just "spring out of my head". I designed them,
>> built them, and they have been reused many times. BUT, the way I put
>> them together has been subject to iterative improvements...
>>
>>
>>
> I've covered that one above. If it's discrete then it shouldn't be an
> enormous challenge.
>
>> It really comes down to how you define a component and opinions vary
>>
>>
> covered that one too.
>
>> <<<
>> I think there may be a misunderstanding about the word "dearth"
>> here... If what is being said is that there are few examples of
>> component use in COBOL,I'd have to agree. So what you do is translate
>> the thousands of examples in VB...(Well, that is what I have learned
>> to do... become quite adept at it now. I still haven't been persuaded
>> to change to developing in VB, although there are times when the
>> economy of VB is attractive.)
>>
>>
>>
> OK two points on that one - and looking at VB is a good idea. I did when
> researching on Treeviews.
>
> (1) I can find justification for including checkboxes in a Treeview -
> on your travels through VB, let me know if you find any referencing
> checkboxes. You've probably picked up on the code from the coloured
> DropListDialog - without having done any research , I suspect something
> like "wmDrawItem" receiving a different parameter structure for
> checkboxes (???).
> M/F's class methods are restricted to Label creation.
>
> (2) Not specifically VB - but applicable to the following controls -
> Treeviews, Lisboxes, Listviews, Droplists - I can find all sorts of info
> - but not once did I find a reference, where having clicked on an item
> and getting its index position, they illustrated how you could get at
> the File PrimeKey/DB ID. There can only, to my mind, be two ways, (a)
> Either your displayable record contains the key, or (b) having created a
> collection for the particular control, you create a separate collection,
> containing keys only - and you reference between the two collections
> using the same index position.
>
> Somewhere I found an MS Treeview example. It allowed you to create and
> add at various Levels. At then end you write the whole shebang to a DB
> Table - using your Labels as DB IDs. What a cop out !
>
>> But the basic component can handle any or all of these features
>> through it's properties. And it never needs to be changed.(That is
>> exactly what PowerCOBOL does... here's a tutorial on it that I wrote
>> some years ago and it has been picked up by several sites in South
>> America: http://ar.geocities.com/pcobolar/tutorial1/tut01001.html
>> (Click where it says "CLICK AQUI")
>>
>>
>>
> You are correct - but here again we are into the interpretation of the
> word "components". There aren't any properties in my DBI examples above.
>
>>> It's worth noting that this is not an OO Reuse problem, but rather
>>> getting a handle on how to use GUI/API features, which is ancillary
>>> to the OO business problem.
>>>
>>
>> <<<
>> Most GUI controls are available as components.
>>
>>
> Depending upon complexity, also at a price. I think decent Treeviews
> come in around $250. Forgotten exchange rate, but that really increments
> in Canadian dollars. And while it serves the problem, back to your
> comment about looking at VB. Why on earth every time we turn around,
> should we borrow or look at examples from other languages. With a bit of
> openness - this info should be available to any COBOLer - a Knowledge
> Base of "How tos....".
>
> Nearly forgot - re SOAP and dot.Net - notice how may of those components
> are now offered specifically for dot.Net. Not having N/E 4, I'm not
> aware of problems. From what you've read, if you have a "non-dot.Net"
> version of F/J or M/F compiler - do you run up against a brick wall
> with dot.Net ?
>
> Jimmy
Well, Jimmy, I am reading it. >G? Don't know how much
is sinking in. I'm a slow learner. Yet, if I get your drift,
you build a tool, and then realize that that same tool
will work in another place. Over time, you see that
extending the abilities of the tool will make it more
universal.That's what I liked about the network database.

When we first tried to do something like bill of materials.
the VENDOR only had a publication on how to code this for
a large drum system we had. Our solution had to include
code within the data storage to handle the various options.
We were ahead of the curve on doing things like this. I'm
sure when IDS was invented, as an example, it was well
received because the size of the disk file was finite.

Now days you can plug in a pencil shaped device to load,
or copy a great deal of information with you. My daughter does this
when she needs to present something to a group. The tools
are part of her operating system, and she has a method she
uses to organize what she will be talking about.

Personally, I would be much more willing to equate
OO to building tools. I can visualize a whole hardware
store full of them. Then someone will come in and ask for
a gizmo I never heard of before, and I can't help him.
I support the idea that use of more worldly words to
define the development of software would be to the advantage of
everyone. How would you like to teach this stuff beginning
every semester with people who have not been introduce to
the concepts in a familiar way.

Most of the problems I see with the universal tool set for business
is that there is a high degree of pride in the home grown
stuff. Yet there seem to be a number of broad applications that
sell well now days. To bad that there is no uniform method
of accounting, or stock trading, or what have you. As one of
my former buddies once said, the only thing wrong with it,
is they won't let me run it. Each of us likes to see the
results in a personal way. One must be very high up in
the organization chart to change some things. Even then
the results may not look exactly alike. For example,
when reading about software, you may find a reference to
apars, tailoring, etc.

I downloaded a program to test the other day that is
a generalized find and replace utility. The author is
from down under. As soon as I got it almost within
the first day, he asked if I needed any help or did I have
any questions.

For you guys, I will admit that what the program does
seems to fit into a tool category. It seems to do
everything anyone ever asked to do. I felt that a few
more pictures would enhance his tutorial. And as he
asked, I told him it looked very comprehensive, but it
take a long time to learn the information in his
explanation unless there were some more illustration.
My only experience with such a tool was with SPF. I still
own a copy of that.

Perhaps my background is not sufficient enough to
think in the levels of those 50 dollar words. I hate
to waste time looking up the definitions and learning
the theory. I only want to use the tool.

You guys keep it up. I have little else to do, and
I am enjoying learning by reading the various strings
here.

Warren