Is Procedural Paradigm a basis of OO Paradigm?
in [OOP]
|
Prev: Need advice on standardizing documentation in a project
Next: Call For Papers (Extended Deadline): WORLDCOMP'07 (June 25-28, 2007, Las Vegas, USA): computer science, computer eng., and applied computing conferences
From: arnuld on 21 Feb 2007 11:03 just changed the subject, to make it more clear
From: H. S. Lahman on 21 Feb 2007 11:44 Responding to Arnuld... > just changed the subject, to make it more clear I have to strongly disagree. The paradigms are almost diametrically opposed. Procedural techniques are based on functional decomposition with its hierarchical dependencies. One can argue that the whole point of the OO paradigm is to eliminate hierarchical dependency structures. All that good OO stuff -- encapsulation, separation of message and method, decoupling, implementation hiding, flexible logical indivisibility, problem space abstraction of intrinsic properties, capturing business rules in static structure, etc., etc. -- plays together expressly to eliminate hierarchical dependencies. ************* There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH
From: Dmitry A. Kazakov on 21 Feb 2007 12:31 In some sense yes it definitely is. Methods are procedures. Their decomposition is procedural. However some types of decomposition are automated (upon inheritance or delegation). Further, for meta programming, OOPLs provide new types of procedures to deal with classes. There is no way to get rid of this sort of decomposition when the number of states is any large. What any procedure does is in fact an abstraction of a set of state transitions. You describe a bunch of transitions like 1->2, 2->3, 3->4, etc by a function inc:N->N. The difference is like between finger counting and arithmetic. Now what OO does (on this basis) is identifying N, the set of natural numbers for which arithmetic works. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Mark Nicholls on 22 Feb 2007 12:53 On 21 Feb, 16:03, "arnuld" <geek.arn...(a)gmail.com> wrote: > just changed the subject, to make it more clear yes..... it is trivial to consider procedural programming as a special case of OO, OO gives you some extra bells and whistles that make life easier (or more complex depending on what hat you've got on).
From: topmind on 22 Feb 2007 13:27
On Feb 22, 9:53 am, "Mark Nicholls" <Nicholls.M...(a)mtvne.com> wrote: > On 21 Feb, 16:03, "arnuld" <geek.arn...(a)gmail.com> wrote: > > > just changed the subject, to make it more clear > > yes..... > > it is trivial to consider procedural programming as a special case of > OO, OO gives you some extra bells and whistles that make life easier > (or more complex depending on what hat you've got on). So does relational. Or functional, or logical programming, etc. You seem to be arguing for paradigm potpurri. Many of the things that people do with OO are better done in relational in my opinion. For example, managing "instance features" with sets instead of graphs of pointers or trees. OO is navigational structures, which were discredited in the 70's and should have stayed that way if the OO hypsters didn't zombie it up from the grave of Bad Ideas. -T- |