Code Comments
Programming Forum and web based access to our favorite programming groups.
OO ReusePrimarily 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, (hi s earlier text was more abs tract/academic), but I think he really hits the nail on the head with the fo llowing. For my money a complete 100% endorsement. Having 'moved around a bi t' on OO technology, I'd bet Donald will probably agree too :- "...... 3. Reusable code only emerges by attempting to reuse it. Just sayin g "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. The only way to have good reusable code is to continuously refine it based on experience. 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. " The above, to those of you who will recall, tends to negate a statement made , a while back, that "Once designed a component is never changed....". The quote above has been my experience. Thepart is we don't have a dear th of examples, (well actually there are none in COBOL). It could only truly take-off in COBOL when developers have other people's ideas, in hard-code, to peruse and adapt. If you think the above quote confirms that REUSE is a lost cause, it isn't. There are degrees of complexity. There is a vast difference between a common (polymorphic) approach to accessing an index or key from lists as I recently illustrated, compared to s ay producing a Treeview, which while GUI based, is heavily supported by Busi ness Logic and collection classes. If you do a Web search on Treeviews for e xamples, they can move from a basic level, a black on white hierarchy, with lines and 'buttons', [+] or [-], (and using a combination of those two, ON/OFF to get different layo uts), progressively up through introduction of Level icons (like the folders you see in Windows Explorer), coloured lines at different levels, and check boxes etc. 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 busines s problem. Jimmy, Calgary AB
Post Follow-up to this message
Re: OO Reuse"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 say ing > "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. " > <<< 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... > The above, to those of you who will recall, tends to negate a statement made, a wh ile back, that "Once designed a component is never changed....". <<< Hahaha! I confess...it was I who said that. (And it is, for the most part, true, as far as I am concerned.) However, I also said a lot more things about components and reuse which are really part of the whole context as to how I see components. Here's the link: http://www.aboutlegacycoding.com/archives/v3/v30201.asp It really comes down to how you define a component and opinions vary widely on that. It's a bit like saying: "A nail will always be a nail and a brick will always be a brick." That was the idea I was sing to convey when I made the statement above. However, we are constanly finding more attractive things to build with nails and bricks... > The quote above has been my experience. The
Post Follow-up to this message Re: OO ReuseJames J. Gavan wrote: > Primarily for Daniel, aww shucks.. *blush* > "...... 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. > > The only way to have good reusable code is to continuously refine it > based on experience. 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. " > > The above, to those of you who will recall, tends to negate a statement > made, a while back, that "Once designed a component is never changed....". I don't think that statement, in its context, conflicts with "3." above. (Although I'm personally hesitant to use the word "never" - I prefer the term "rarely".) I'm thinking specifically about PECD's String2Num component that he's used as an example of how he builds components. I'm sure he didn't write all those formats in the first time (unless he's more of a genius that I think he is already) - he probably did some validation to begin with, and then, as he saw the need, put more formats in it. The other possibility is that he had disparate validation stuff scattered around through his code, and said "Hey, you know, I could put these all together, then use it all over the place. I could you on my next project too!" One could make the argument that under the first theory, the component wasn't fully "designed" until all the formats were there. A mature component could be a collection of a lot of smaller components, also. Thinking about String2Num, it could be a shell for ValidateString, StringToDB, StringToDate, etc... Thanks for the quote... :) -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~ ~ / \ / ~ Live from Montgomery, AL! ~ ~ / \/ o ~ ~ ~ / /\ - | ~ LXi0007@Netscape.net ~ ~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ I do not read e-mail at the above address ~ ~ Please see website if you wish to contact me privately ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~
Post Follow-up to this message Re: OO ReuseDon't you hate it when people talk about you as if you're not there? :-) (OK, I know i'm not here most of the time, but it only takes an e-mail to remove all speculation...) Comments below... LX-i <lxi0007@netscape.net> wrote in message news:<10at9uvnqp34o35@corp.supernews.com>...[c olor=darkred] > James J. Gavan wrote: > > > aww shucks.. *blush* > > > I don't think that statement, in its context, conflicts with "3." above. > (Although I'm personally hesitant to use the word "never" - I prefer > the term "rarely".)[/color] <<< That is very fair comment. I was speaking purely for myself. Many years ago when we had to code COBOL onto coding pads, it was common practice to write the code in pencil. If you made mistakes, you simply erased the error and corrected it. Not me. I coded in ink. Many of my colleagues couldn't understand how I could do this and not make errors. I "educated" my mind to COBOL syntax by imposing a "punishment" on myself if I got it wrong. The deal was that I had to recode the ENTIRE PAGE, no crossing out or Tipex allowed. After a w
Post Follow-up to this message Re: OO ReusePeter E. C. Dashwood wrote: >"James J. Gavan" <jjgavan@shaw.ca> wrote in message news:<jahrc.552448$Ig.2 70662@pd7tw2no>... > > >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 :- > > ><<< >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... > > > ><<< >Absolutely. I have always advocated the iterative approach. > > > ><<< > > 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 bullshit 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/tu...1/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. ><<< >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
Post Follow-up to this message Re: OO ReuseJames J. Gavan wrote: > Peter E. C. Dashwood wrote: > > > 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 [-] t o 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 > bullshit 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 . > > I've covered that one above. If it's discrete then it shouldn't be an > enormous challenge. > > covered that one too. > > 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 ! > > 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. > > 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
Post Follow-up to this message Re: OO ReuseWarren Simmons wrote: > 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, Couple of points where you are specifically on the ball - like we really would rather have it written by ourselves. Well not quite, "I would rather have it written in COBOL, because I can interact better". I do agree with you about those $50 words. First book was Ed Arranga/Frank Coyle - they did mention some of the $50 stuff, but without confusing with the embellished names. As reference they referred to the jazz "Is a something ?", or "Has a something ?", and CRC cards - which are little box cards on which you write various attributes/properties per object you come across in your design. Does a true COBOL programmer need those CRC cards - I think not. I'm willing to bet many COBOLers who have looked at OO, apart from the two books I'm always recommending, are absolutely turned off by the theoretical crap. It's a couple of years back now, but I recall somebody writing, "Yeah I get this inheritance thing, but what have cows, pigs, horses, camels, chickens, ducks and geese got to do with programming COBOL" :-) My heart went out to him. Funnily enough, not that I think those CRC cards are relevant, but it made me reflect on my early days in systems analysis which started summer of '63 - I think you got going on programming in the late fifties. Of all the phases I enjoyed most was Stage # 1 - the conceptual stage. Nothing around to copy so we had a complete blank page. Specification given to us "Design an invoicing system". No rules no nuthin'. So in the dining room of an 18th century house, (
Post Follow-up to this message Re: OO ReuseHi Jimmy, some considered observations here... I have taken some time over this and tried to address your points. Obviously, there are areas of disagreement here. I have neither time nor inclination to extend this into a long CLC argument. My post is not intended to be hostile and neither is it personal. Take what you can use. Pete. > > 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 ! <<< This has not been my experience. > Let's move beyond discrete reasonably defined components to some of the > more challenging ones - <<< Why? This is where it is falling down. You are expecting a brick to be a patio, then complaining because your patio can't be a wall. "The more challenging ones" are arguably NOT components. There is a big difference between component based systems and components, just as there is a big difference between a patio and a brick. > 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 [-] t o 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. That is why you use NODE components to build a Treeview component. You can combine nodes in any way you like, and the fundamental maintenance operations are already built in. Also the base automatically takes care of levels by positioning nodes at the right level in the Treeview (dependant or sibling), based on properties (which you seem to have omitted.) > > 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). It has whatever impact you decide. You're the programmer... I know you have done a lot of good work with collections. Have you looked at nodes as a specific type of collection? If you do, you will realise that it is possible to have any number of "levels" each with its own key, so you can, in effect, have a key for any and every level, without adding any more code. It is a fundamental property of the node object. You are building something that "probably won't go below 4 levels" then grizzling because it is difficult to reuse. If you built something that would handle ANY number of levels it would have much more chance of being reusable. This is a common design "flaw". People think in terms of what they are going to use, rather than generalising or abstracting the solution. That is why you need to maintain things. (And that is why I don't...comes back to my statement about components not requiring maintenance). One day level five comes along... Building a treeview "component" simply becomes a case of collecting node objects and ensuring their properties are accessible, with the addition of a few overall properties to "glue" it all together. I covered it in the Treeview tutorial I referenced previously. You dynamically add levels to your Treeview at runtime using a node constructor. The Tutorial also shows how to load the treeview and sort the nodes in it. Sample OO code is provided. There is nothing mysterious or difficult about treeviews, PROVIDED you stop thinking of them as a vehicle to display COBOL records, and start thinking of them as generalised structures that can display nodular data in a hierarchic fashion. > > 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 > bullshit associated with OO. <<< I don't think so, Jimmy. It is easy to write theory off as bullshit if you don't understand it. I would certainly agree that there is a lot of jargon in OO, but I believe that is normal with most fields of endeavour. I would further agree that you don't need to be familiar with all of the jargon and all of the theory to write functioning OO programs or components. What happens is that something is described using certain "new" terms. After a lot of work and practise we get to grips with it and then realise that it is very similar to another concept we already know. "So why did they give us all that bullshit? Couldn't they have said from the start that it's just a slightly modified whatever?" Normal reaction. But it is neither fair nor accurate. What about the people who never encountered a whatever in their lives? What about the fact that it is actually subtly different from whatever, but we missed that subtlety because we already determined it was a whatever? I think you see what I'm getting at. Reuse is a fact of life at my place. Jargon or no jargon, definitions or no definitions, I reuse components and large parts of component based systems all the time. No problem. A brick is a brick, a nail is a nail. > 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 ? > <<< Er...yes, sometimes. I picked this up from Wil Price's book and find it an excellent technique for deciding whether something should be a Property or a Method. I noticed (with some surprise) that you haven't considered properties in your Treeview solution. > > 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. <<< No you don't. Sales-this-Month and Sales-year-to-Date are derivable and don't need to be held at all. The non-derivable items can be properties of the transaction object and customer object. The database is simply a repository that allows the properties to be saved and restored, as objects are created and destroyed. There are many ways to do this and it doesn't HAVE to be the way you describe. I would use an ADO object attached to each Customer or Transaction object to get and put data to a database (or I might use embedded SQL, just because I love it <G> ). BUT, that has nothing to do with the design of my treeview. The only thing I would definitely NOT do is try and integrate the database components with the Treeview component; these are separate layers of the multi-tier design. > > 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 !. <<< But he is certainly better informed <G>. Jimmy, because you personally may have a problem with abstraction doesn't mean that everyone does. Young people are especially good at it in my experience. He is probably talking about a game which allows Monsters etc. to be manipulated as objects. Many games do this. I have a couple where you can develop your own scenarios and provide your own backgrounds and objects. Kids who spend all day playing these games have little difficulty in understanding that a Hero object (for instance) has properties like Resistance to attack, Experience, Kill levels, special skills, name, etc. without necessarily understanding the OO concept of an Object Property. Given a toolkit to manipulate these objects they take to it like ducks to water. They are not bogged down with programming backgrounds, thinking about files and records and data hierarchies. (I speak with some authority on this as I have a Godson in Canada who is REALLY into gaming and I realized from our correspondence some time ago that his concept of computing and mine are a long way apart <g>. Nevertheless, he successfully builds, plays, and evaluates games using OO without even knowing it...Occasionally he will come to the Godfather requesting technical assistance that is platform related <G>, but when it comes to Graphics hardware and gaming, I would go to him. (He is 20 years old.) > > 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. Well, at least you are making progress. I don't want to comment on the approach because that is a personal thing and isn't necessarily right or wrong. All I will say is that I wouldn't start with database design. I'd begin by defining objects and then assigning properties and methods to them. (That will automatically drive out the database design later...) > > 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 :-) . > If it makes you feel any better, I believe we all suffer from that at some stage. I certainly do... The trick is to realize you made an error. That's where procedures can help. I use paper models, but that is only one way... > 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 . <<<< You definitely need to review the idea of tiered design. And think about what is static and what is dynamic. > > I've covered that one above. If it's discrete then it shouldn't be an > enormous challenge. <<< String2Num is trivial (but nevertheless extremely useful). I'm not sure what you mean by "discrete" here. If you mean something that is isolated from all other functions then surely that is true for all components? While Classes in OO may interact directly and even extend each other and inherit from each other, components generally don't. (At least not by definition or instantiation...components are encapsulated functionality. A brick cannot be half brick and half nail, or sometimes brick...). The exception would be where a component has been written using OO Classes whose methods and properties it exposes publicly. That is like a brick inheriting the colour "red" or "yellow". It is still a brick.) > > covered that one too. > <<< As you snipped it without comment, we will never know... So, I can take it that my following precis of what I thought you meant, is, in fact, accurate? > 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. <<< Nope. You've lost me here. For me, a treeview is created with checkboxes if you set that creation property to TRUE. (It works because node objects can store graphics and icons as well as textual data.) > > (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. <<< What about the DB ID being the index in the collection? Obviously, if the collection changes, you would need to update the database, but a bound DB component will do that automatically for you. Please think about option (b) again... it is ugly and probably non-viable. > > 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 ! <<< Well, I wouldn't do it quite like that, but I don't see that something which works is a cop out... What is it in this that you object to? Storing an object's properties as a row of data in a RDB table is fairly standard practice. > > 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. <<< I am firmly persuaded that there should be...<G> > > 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....". Why? Are you suggesting that people writing COBOL OO Classes should make the source public? What about competitive advantage? Doesn't this forum and Bill's COBOL FAQs serve as a knowledge base of "How to"s? Encouraging students and giving basic help on coding COBOL is one thing; providing solutions to advanced coding problems is quite another. I certainly respond here when people ask me to. I've just posted a bunch of code on using XML objects with COBOL. But I don't consider it is incumbent on me to do so, or that people have a God-given right to demand solutions. How do you think I arrived at these solutions? It takes sweat and ingenuity. Is that worth nothing? If somebody charges $250 for a component that you cannot write yourself or it would take you some months to write and debug, isn't the labourer worthy of his hire? All of the people who post solutions here, including yourself, Jimmy, do so out of the goodness of their hearts and from a desire to promote the use of COBOL. If it requires going to other languages then that is what people should do, or genuinely request assistance if they don't have the skill, in which case they should be prepared to pay for it. (Whether they actually get charged or not is up to the person providing the solution. My point is about an attitude.) I'm really a bit tired of providing valuable information for free and never even getting a "thank you" in many cases. I posted the XML stuff because several people were looking for assistance in this area and there are likely to be more. They are all people with the right attitude (I have no doubt they would (and have, in at least one case)provide information to me, if I needed/asked for it.). And it didn't cost me to do it. I am wary when people start saying "should"... > > 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 ? <<< No. Not yet. Non-CLR code still runs for the moment. We'll have to see how long that situation lasts... > > Jimmy
Post Follow-up to this message Re: OO ReuseJames J. Gavan wrote: > Warren Simmons wrote: > > > > Warren, > > Couple of points where you are specifically on the ball - like we really > would rather have it written by ourselves. > Well not quite, "I would rather have it written in COBOL, because I can > interact better". > > I do agree with you about those $50 words. First book was Ed > Arranga/Frank Coyle - they did mention some of the > $50 stuff, but without confusing with the embellished names. As > reference they referred to the jazz "Is a something ?", or "Has a > something ?", and CRC cards - which are little box cards on which you > write various attributes/properties per object you come across in your > design. Does a true COBOL programmer need those CRC cards - I think not. > I'm willing to bet many COBOLers who have looked at OO, apart from the > two books I'm always recommending, are absolutely turned off by the > theoretical crap. It's a couple of years back now, but I recall somebody > writing, "Yeah I get this inheritance thing, but what have cows, pigs, > horses, camels, chickens, ducks and geese got to do with programming > COBOL" :-) My heart went out to him. > > Funnily enough, not that I think those CRC cards are relevant, but it > made me reflect on my early days in systems analysis which started > summer of '63 - I think you got going on programming in the late > fifties. Of all the phases I enjoyed most was Stage # 1 - the > conceptual stage. Nothing around to copy so we had a complete blank > page. Specification given to us "Design an invoicing system". No rules > no nuthin'. So in the dining room of an 18th century house, (
Post Follow-up to this message Re: OO ReusePeter E. C. Dashwood wrote: > Don't you hate it when people talk about you as if you're not there? > :-) > (OK, I know i'm not here most of the time, but it only takes an e-mail > to remove all speculation...) I figured if you were lurking, it might draw you out of the shadows - then, lo and behold, right when I've laid my trap, you post a message about SOAP. :) > Comments below... > > LX-i <lxi0007@netscape.net> wrote in message news:<10at9uvnqp34o35@corp.su pernews.com>... > > > <<< > That is very fair comment. I was speaking purely for myself. > > Many years ago when we had to code COBOL onto coding pads, it was > common practice to write the code in pencil. If you made mistakes, you > simply erased the error and corrected it. Sounds logical... > Not me. I coded in ink. Many of my colleagues couldn't understand how > I could do this and not make errors. I "educated" my mind to COBOL > syntax by imposing a "punishment" on myself if I got it wrong. The > deal was that I had to recode the ENTIRE PAGE, no crossing out or > Tipex allowed. After a w
Post Follow-up to this message
Sponsored Links
Powered by vBulletin
Copyright 2000-2006 Jelsoft Enterprises Limited.
