On Sat, 14 Jul 2007 19:18:05 +0530, "Rustom Mody" <[EMAIL PROTECTED]> wrote:
>On 7/14/07, Alex Martelli <[EMAIL PROTECTED]> wrote: >> >> OOP can be abused (particularly with deep or intricate inheritance >> structures). But the base concept is simple and clear: you can bundle >> state and behavior into a stateful "black box" (of which you may make as >> many instances, with independent state but equal behavior, as you need). >> > >Many years ago (86??) Wegner wrote a paper in OOPSLA called Dimensions >of Object Orientation in which he called the 'base concept' of 'bundle >of state and behavior' as 'object based' programming and >'object-oriented' as object-based + inheritance. Not quite--according to him: object-based + classes => class-based class-based + class inheritance => object-oriented I.e., "object-oriented = objects + classes + inheritance". This was not the, by then, standard definition: to be OO would require all four of: 1. modularity (class-based? object-based?) 2. inheritance (sub-classing) 3. encapsulation (information hiding) 4. polymorphism ((sub-) class-specific response to a message, or processing of a method) Unfortunately, most of the "definitions" (usually just hand-waving, loosey-goosey descriptions) found on the web include none--or only one or two--of these fundamental requirements by name, and are so loose that almost any proramming paradigm or style would be OO. >What Alex is saying is (in effect) that object-based is simple and >clear (and useful) whereas the object-orientation is subject to abuse. But OO is also simple and clear (if clearly defined and explained and illustrated and implemented), and ANY programming style is subject to abuse. During the hey-day of Pascal as an introductory programming language (as often misused as more than that) I found many often spent much of their time defining the data types their program would use. >This anyway is my experience: C++ programmers are distinctly poorer >programmers than C programmers -- for some strange reason closeness to >the machine has a salutary effect whereas the encouragment of >uselessly over-engineered programs makes worse programmers. But this is a tautology: "over-engineered" programs are, by definition or terminology, not a good thing--independent of what PL or style they're finally implemented in (assuming that by "engineering" you mean "design" or similar). Many of my Pascal students over-engineered their solutions to simple problems too? >GUI is one of those cases wherein inheritance actually helps people >produce better code but this is something of an exception. This seems to imply that the list of applications you have in mind or have worked on includes fewer domains that might profit from full OO instead of just OB. My guess is that there are many application domains in which analysts and programmers often think in an "OO way", but implement in just an OB way because of the PL they or their employer requires or prefers: in some--perhaps many--of these cases they have to do "manually" what OO would have automated. There is a problem, though, of (especially university and college) education and training in OOP "talking about" how glorious OO is, and requiring students to use OO techniques whether they're most appropriate or not (the "classes early" pedagogical mindset). And this problem is compounded by teaching introductory programming using a language like Java that requires one to use an OO style for even trivial programs. And by using one of the many very similar introductory texbooks that talk a lot about OO before actually getting started on programming, so students don't realize how trivial a program is required to solve a trivial problem, and hence look for complexity everywhere--whether it exists or not--and spend a lot of time supposedly reducing the complexity of an already simple problem and its method of solution. But as I noted above, a similar problem occurred with the crop of students who first learned Pascal: they often spent much of their time defining the data types their program would use, just as OO (especially "classes early") graduates tend to waste time "over-subclassing" and developing libraries of little-used classes. The answer is always balance, and having an extensive enough toolkit that one is not forced or encouraged to apply a programming model that isn't appropriate and doesn't help in any way (including maintainability). And starting with a language that doesn't brainwash one into believing that the style it enforces or implies is always the best--and texbooks that teach proper choice of programming style instead of rigid adherence to one. wwwayne -- http://mail.python.org/mailman/listinfo/python-list
