Interesting take on Paradigms (OO vs Procedural)
in [Cobol]
|
From: Pete Dashwood on 12 Apr 2008 02:55 "Rick Smith" <ricksmith(a)mfi.net> wrote in message news:Z4CdncSCCf-RM2LanZ2dnUVZ_hisnZ2d(a)mid-floridainternet... > > "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message > news:6688cfF2ii6kvU1(a)mid.individual.net... >> >> >> "Joe Zitzelberger" <zberger(a)knology.net> wrote in message >> news:zberger-A7F0BE.00153011042008(a)ispnews.usenetserver.com... > [snip] >> > You can certainly use OO compilers to write procedural type code as you >> > describe -- or you can use procedural only compilers to write OO style >> > code as long as you enforce your the OO rules yourself. >> >> Absolutely. The fact is that when you encapsulate behaviours and > properties >> into an Object, the synergistic whole, is far greater than the sum of its >> parts. The code representation is only ONE aspect of it. > > Pete, sometimes you make it too difficult for me > to not care! <g> How you feel about things is entirely a matter for you, just as how I feel about things is up to me. Generally, you make it VERY easy for me to stop caring...:-) > > The fact is that were one to encapsulate behaviors and > properties into (a COBOL 68 program as) an object, it > would not be more than what it appears to be. I make a simple statement, intended to express a concept. (There is a synergy obtained when you create objects. Part of that synergy is the fact that you can use objects in many ways OUTSIDE of expressing them as computer code.) "The fact is that when you encapsulate behaviours and properties into an Object, the synergistic whole, is far greater than the sum of its parts. The code representation is only ONE aspect of it." But ALL you see is the code representation. (So what about your OOA and OOD? Is OOP ALL you can actually see? Yes, of course, your Object Oriented Analysis is designed to derive objects to be coded and your Object Oriented Design is intended to optimise them in code, so your OOP can manipulate them in code. That is the full extent of your interest.) "Oh no, Pete. If I do that with COBOL 68 I don't have any synergy..." Well, Gee, Rick... might be time you moved off COBOL 68. (See how easy it is for me to stop caring about the whole discussion when I am dealing with someone who relates what I say to a compiler from 40 years ago, that never supported OO anyway? It's just silly.) And you're wrong anyway. Whether or not it was "more than what it appears to be" depends on how imaginatively you use it. If the various methods were written as entry points, they could be activated independently of each other but sharing "factory" data, so the module already has a capability that it wouldn't have were it written as a series of modules to implement each method in the usual COBOL way. >Add > inheritance and polymorphism and the picture changes > dramatically. The ability to substitute (an object of) one > subclass with (an object of) another subclass (both > derived from the same class), with no change to the > underlying code, is what I see as synergistic. Yes, but how dry is that. > > [I think the above also helps demonstrate why "object" > should not be used. It is difficult to define a proper > relationship between objects without reference to "class".] > I don't find myself discussing relationships between objects of a class very often in these discussions, so "object" serves perfectly well as a general description of what I'm talking about. Should the need arise to discuss specific objects, and confusion is possible I would simply use dot notation: Class.Object. But I don't expect to be discussing this further anyway, so it is moot. Pete. -- I used to write COBOL...now I can do anything."
From: Charles Hottel on 12 Apr 2008 12:14 "Rick Smith" <ricksmith(a)mfi.net> wrote in message news:Z4CdncSCCf-RM2LanZ2dnUVZ_hisnZ2d(a)mid-floridainternet... > > "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message > news:6688cfF2ii6kvU1(a)mid.individual.net... >> >> >> "Joe Zitzelberger" <zberger(a)knology.net> wrote in message >> news:zberger-A7F0BE.00153011042008(a)ispnews.usenetserver.com... > [snip] >> > You can certainly use OO compilers to write procedural type code as you >> > describe -- or you can use procedural only compilers to write OO style >> > code as long as you enforce your the OO rules yourself. >> >> Absolutely. The fact is that when you encapsulate behaviours and > properties >> into an Object, the synergistic whole, is far greater than the sum of its >> parts. The code representation is only ONE aspect of it. > > Pete, sometimes you make it too difficult for me > to not care! <g> > > The fact is that were one to encapsulate behaviors and > properties into (a COBOL 68 program as) an object, it > would not be more than what it appears to be. Add > inheritance and polymorphism and the picture changes > dramatically. The ability to substitute (an object of) one > subclass with (an object of) another subclass (both > derived from the same class), with no change to the > underlying code, is what I see as synergistic. > > [I think the above also helps demonstrate why "object" > should not be used. It is difficult to define a proper > relationship between objects without reference to "class".] > > I think you can make a case to prefer "class based programming" to "object oriented programming" but the hard facts of reality are that that ship has sailed. It is important to understand the difference between a "class" and an "object", especially because you will find very sloppy usage of these terms in general. Understanding them helps you read between the lines an determine for yourself what the author really means. Sometimes I think that understanding them is what leads to sloppy use of the terms. People intuitively understand what they mean to say, but they have forgotten their inital confusion and are not as precise as they need to be when explaining ideas to beginners. Likewise the term "interface" often has several meaning and you must determine from the context which one is meant.
From: Rick Smith on 12 Apr 2008 13:47 "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message news:66b4muF2jli9bU1(a)mid.individual.net... > > "Rick Smith" <ricksmith(a)mfi.net> wrote in message > news:Z4CdncSCCf-RM2LanZ2dnUVZ_hisnZ2d(a)mid-floridainternet... [snip] > > > > The fact is that were one to encapsulate behaviors and > > properties into (a COBOL 68 program as) an object, it > > would not be more than what it appears to be. > > I make a simple statement, intended to express a concept. (There is a > synergy obtained when you create objects. Part of that synergy is the fact > that you can use objects in many ways OUTSIDE of expressing them as computer > code.) Please note the use of the plural "objects". > "The fact is that when you encapsulate behaviours and properties into an > Object, the synergistic whole, is far greater than the sum of its > parts. The code representation is only ONE aspect of it." Please note the use of the singular "Object" preceded by "an" suggesting an intent to use the singular. Pete, make up your mind! <g> My response was predicated on your use of the singular, meaning that the "synergistic whole" is encapsulated within one object. [snip] > "Oh no, Pete. If I do that with COBOL 68 I don't have any synergy..." > > Well, Gee, Rick... might be time you moved off COBOL 68. My references to COBOL 68 demonstrate that the *academic* definition of "object" is so broad that even a language that can not be use in object-oriented progamming is included. This renders the definition of "object" absurd and impractical.
From: Rick Smith on 12 Apr 2008 14:42 "Rick Smith" <ricksmith(a)mfi.net> wrote in message news:h8-dnR5z4bcjaJ3VnZ2dnUVZ_jmdnZ2d(a)mid-floridainternet... [snip] > Pete, make up your mind! <g> My response was predicated > on your use of the singular, meaning that the "synergistic > whole" is encapsulated within one object. I might have expressed that better as "..., meaning that the 'synergistic whole' is that which is encapsulated within each object." My apologies.
From: Rick Smith on 12 Apr 2008 15:11
"Charles Hottel" <chottel(a)earthlink.net> wrote in message news:AtCdnRqpKKdHQp3VnZ2dnUVZ_gudnZ2d(a)earthlink.com... [snip] > I think you can make a case to prefer "class based programming" to "object > oriented programming" but the hard facts of reality are that that ship has > sailed. As of Thursday, April 10th, when I found these references, Wikipedia shows 111 object-oriented progamming languages < http://en.wikipedia.org/wiki/Category:Object-oriented_programming_languages > and 36 class-based progamming languages < http://en.wikipedia.org/wiki/Category:Class-based_programming_languages >. I am not sure one can trust these lists because C++ shows as class-based but not object-oriented. The latter web page, above, states: ----- This category lists all object-oriented programming languages which adhere to the Class-based programming paradigm. ----- This suggests that those who created this page consider class-based to be a subset of object-oriented; thus inheriting the definition of a term ("object") that I find objectionable. |