Did I write a good (efficient) program?
in [Cobol]
|
From: Howard Brazee on 4 Apr 2008 09:53 On Thu, 3 Apr 2008 19:31:14 -0500, "Rick Smith" <ricksmith(a)mfi.net> wrote: >Therein lies the problem, Mr Dashwood! While you advocate >the OO paradigm, you don't actually use it--preferring your own >principles to those of the paradigm. <g> If OO is a tool, and not a religion - he is free to use what parts are useful to produce the desired product. Same thing with relational databases and 2x4s.
From: SkippyPB on 4 Apr 2008 11:08 On Thu, 03 Apr 2008 10:01:01 -0600, Howard Brazee <howard(a)brazee.net> wrote: >On Thu, 03 Apr 2008 11:46:22 -0400, SkippyPB ><swiegand(a)nospam.neo.rr.com> wrote: > >>Probably my fault. I wasn't following the thread that closely and I >>obviously missed the sarcasm. I, however, can understand why >>applications' programmers may have difficulty doing systems work. If >>you are knowledgeable in IBM Assembler, then systems work should not >>be that difficult. However if you've spent your whole career doing >>COBOL, RPG etc, it would be difficult to make the transition. >> >>Although nowadays there is little need to dive down into the nuts and >>bolts of things like it used to be in the late 70's and early 80's >>when I was doing that sort of thing. > >Just like everywhere else - we use bigger components. But when the >*system* now can include parts that aren't anywhere near the computer >room, the scope is different. > >>On the other hand, a lot of systems programmers could graduate to >>applications work though I think most would find it distasteful. > >Applications are what pay for everything. But systems work now moves >into interfacing with people, creating secure & private business >practices and such. True. The systems people that I still talk with are more involved in putting up secure networks than installating the latest release of zOS. Not that they don't do that, it is just that the operating system changes and third party systems like schedulers, remote print, transmissions, etc. etc. have fewer revisions per year and there are more pressing needs. Security and DASD management are highest on their lists. Regards, //// (o o) -oOO--(_)--OOo- "Save the whales. Collect the whole set." -- Steven Wright ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Remove nospam to email me. Steve
From: Rick Smith on 4 Apr 2008 12:20 "Howard Brazee" <howard(a)brazee.net> wrote in message news:bjccv3dhk21osd4upu7ct4r2poc3ustjrc(a)4ax.com... > On Thu, 3 Apr 2008 19:31:14 -0500, "Rick Smith" <ricksmith(a)mfi.net> > wrote: > > >Therein lies the problem, Mr Dashwood! While you advocate > >the OO paradigm, you don't actually use it--preferring your own > >principles to those of the paradigm. <g> > > If OO is a tool, and not a religion - he is free to use what parts are > useful to produce the desired product. > > Same thing with relational databases and 2x4s. If language is to be used for communication, then calling a combination of parts from a Toyota, a Ford, and a Yugo, a Mercedes-Benz, isn't going to communicate accurately the composite; though Toy-For-Yu would at least indicate a composite. To understand others, I rely on definitions and usages supplied by sources I find credible. According to those sources, the OO paradigm consists of three parts: OOA, OOD, and OOP, with OOD the linchpin. Any marked deviation from the principles of OOD means thar OO paradigm does not apply. I may be confused by the choices others make; but, if it has no direct effect on me, I have learned not to care that much about what others do. Abuse of a term I have spent years to understand well does have a direct affect on me.
From: Howard Brazee on 4 Apr 2008 13:46 On Fri, 4 Apr 2008 11:20:56 -0500, "Rick Smith" <ricksmith(a)mfi.net> wrote: >> If OO is a tool, and not a religion - he is free to use what parts are >> useful to produce the desired product. >> >> Same thing with relational databases and 2x4s. > >If language is to be used for communication, then calling >a combination of parts from a Toyota, a Ford, and a Yugo, >a Mercedes-Benz, isn't going to communicate accurately the >composite; though Toy-For-Yu would at least indicate a >composite. Good point - but I've never come across any shop that use Reuse or class maintenance to the extent that were promised. So should we use the language to match the theory, or should we use the language to match what actually happens? Probably both - recognizing the imprecise nature of language, and looking more closely.
From: Rick Smith on 4 Apr 2008 14:58
"Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message news:65men3F2h47fuU1(a)mid.individual.net... > > > "Rick Smith" <ricksmith(a)mfi.net> wrote in message > news:L9ydncNEK_U0YGjanZ2dnUVZ_ternZ2d(a)mid-floridainternet... > > > > "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message > > news:65lo9dF2gqp30U1(a)mid.individual.net... > >> > >> > >> "Rick Smith" <ricksmith(a)mfi.net> wrote in message > >> news:l6KdnaVTeOZ762janZ2dnUVZ_rSrnZ2d(a)mid-floridainternet... > >> > > >> > "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message > >> > news:65k1fkF2gdg4dU1(a)mid.individual.net... > >> >> > >> >> > >> >> "Rick Smith" <ricksmith(a)mfi.net> wrote in message > >> >> news:3vednXJ8aMTLxWnanZ2dnUVZ_q2hnZ2d(a)mid-floridainternet... > >> >> > > >> >> > "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in > >> >> > message > >> >> > news:65fmhdF2fbsenU1(a)mid.individual.net... > >> >> > [snip] > >> >> >> To modify existing functionality does NOT mean modifying a base > > class. > >> > It > >> >> >> means extending (through inheritance) or over-riding existing > >> > behaviours. > >> >> > > >> >> > The priniples of object-oriented design do not include > >> >> > the use of inheritance to overcome inadequate or faulty > >> >> > design. In such cases, modifying a base class may be > >> >> > unavoidable. > >> >> > >> >> I have never encountered such a situation and do not expect to. (Guess > > my > >> >> designs are not "inadequate" or "faulty"...:-)) > >> >> > >> >> I really don't care about academic "principles of OO design" unless > > they > >> > are > >> >> pertinent to the world in which I live and work; your statement above > > is > >> >> not. > >> >> > >> >> My own principles (derived from over a decade of real world use) tell > > me > >> > not > >> >> to modify a Base Class. > >> >> > >> >> So I don't. > >> > > >> > Therein lies the problem, Mr Dashwood! While you advocate > >> > the OO paradigm, you don't actually use it--preferring your own > >> > principles to those of the paradigm. <g> > >> > >> And how is having things work properly, a "problem"? > >> > >> I use the OO paradigm, I may differ with you over interpretation of some > >> aspects of it. > >> > >> Fortunately, I don't need your or your Professor's approval, nor anything > >> written in a text book, in order to make money with it. > >> > >> No problem. > > > > Huh! ... "differ ... over interpretation of some aspects"? > > It's more on the order of I can not find any commonality > > between the OO paradigm and The Dashwood Paradigm, > > except the use of an OOPL. I do, however, find a lot of > > commonality between The Dashwood Paradigm and > > "procedure-based, bottom-up design, with an OOPL"; > > You have no idea of how I design stuff or the modelling processes I use. It > is NOT procedural, it is totally Object based. > > It cannot be "bottom up design" when it is approached from a top down > perspective. Top down is a term used with the procedural paradigm. <g> > It is not about OOPL it is about a holistic approach which only recognises > Classes and Objects at a conceptual AND a programming level. > > > and I rather like that; but to call this "OO paradigm" is > > just plain wrong. > > OK, I won't call it that if it offends you. I really don't care... :-) Thank you. > > > > Consider that bottom-up design in procedural programming > > (not to be confused with the procedural paradigm) may be > > used to develop reusable components; but sometimes such > > components do not have a good fit. Using inheritance in an > > OOPL to correct for that makes it better fit; but using > > inheritance in this manner is not consistent with OOD. > > And we already established that I don't do that so what are you arguing > about? (The only point of issue here is your statement that sometimes Base > Classes HAVE to be amended. I disagree, (I'd rather scrap a base class and > rewrite it than amend it; I DON'T use inheritance to fix flaws in the Class > and would never do that), and suddenly, according to you (an expert in > procedural COBOL...) I don't understand OO...? While I am not certain how the result of rewriting a base class is any different than amending it, that is not really the issue. You wrote "To modify existing functionality ... means ... over-riding existing behaviours". The problem in doing that is that the subclass is not a proper member of the superclass. The recommendation is to refactor the superclass to make both subclasses proper members of the base class. In essence, this is done to correct a design flaw. Instead of (admittedly contrived example) Class-id. DDB-depreciation inherits Depreciation. Method-id. Calculate-depreciation. where the method only calculates straight-line depreciation. Use Class-id. SL-depreciation inherits Depreciation-method. Method-id. Calculate-depreciation. Class-id. DDB-depreciation inherits Depreciation-method. Method-id. Calculate-depreciation. So that the over-ridden behavior of the superclass is now in a subclass and the new behavior is in a separate subclass, thus making both subclasses proper members of the base or superclass. I understand this is not what you do because parts of the evolving application already depend on the base class. > Have I ever claimed my approach uses OOD in a formal way? No. However, advising others to do what is contrary to the principles of OOD is problematic. > I certainly design around Objects (more correctly Classes...) but I have > never claimed I am implementing formal OOD. I use Use Case modelling and > paper models (along with a number of other approaches if the situation > warrants it) and I derive Objects with behaviours and properties from that. > I really don't care what you call it, but it certainly isn't procedural. Using a RDBMS where the data is in representational form breaks encapsulation. This is not necessarily a problem, but the separation of data from its behavior means that the RDBMS is, in effect, a procedural foundation upon which the application is built. In OOD, object storage is an implementation detail and the storage medium and format are irrelevant outside the application. However, it is the passing of data ("getters and setters") among objects that is problematic. If data is shared by multiple objects then it appears that methods defined in different classes are performing procedures on or with that data. > This is just silly and unless you can show some reasonable basis for > disagreeing, I won't be responding. > > A pedantic argumernt based on your understanding of what you THINK I do, is > going nowhere for either of us. Hey, if it walks like a duck and quacks like a duck .... <g> |