Moritz: I started programming in Perl and then some C. I made heavy use of multi-dimensional arrays to store large amounts of data. Then when I came to Python, PHP and Java I really learned to like the OOP approach to programming, making it more easily to handle data, not having to remember the structure of multidimensional arrays. Now, I just had to think what disadvantages OOP has. What do you think?
Let's distinguish two sorts of disadvantages:
Peter Newman 24 January 2005: To me, the main problem with OO is that some implementations (eg; C++) make it way too complicated and obscure. For example, a description of OO in C++ will be loaded with terms like:-
What the hell is all that crap? And who cares? I just wanna write a program.
But there are simple OO like systems that to me work well:-
label .mLabel .myLabel -text "Hello, World!"
where .myLabel, once created can be thought of as an object with ID .myLabel and property -text, etc. And:-
It seems to me that there some important and useful things in OO. But exactly what those useful essentials are, I'm not sure. Tk and Javascript are useful (and used by lots of programmers) - because they obviously use the useful bits. Complicated systems like C++ seem to be rejected by many programmers - in my opinion because they drown the useful bits in a sea of what seems to me to be irrelevant fluff.
But it would be useful to identify exactly what the useful bits of OO were. And thus, in what situations an OO approach is likely to be better/easier than a procedural/command-oriented approach.
Artur Trzewik Tk is not object oriented
Many Tcl-er think that the main characterisitc of object orientation is only the parameter order in commands call. So they show such examples
# procedural close $filehandle # object oriented $filehandle close
Object orientation is much more (see http://en.wikipedia.org/wiki/Object-oriented_programming ). At least object oriented languages needs inheritance, polymorphism, encapsulation, abstraction and objects.
The main difference between procedural and object oriented programming is that the functional programmer try to split function and data (data structures). But object oriented programmer think in objects that is how to hold data und functions (methods) together in one structure.
Because Tcl is string based it also has a kinf of polymorphism. For example Tk:
$button -configure text "Text" $label -configure text "Text"
It looks like object oriented but indeed Tk does not supports inheritance (anyway Tix try it). So button and label has no parent class and you can not derive new widget directly from button.
It is quite unproductive to compare Tcl as procedural language with C++ Java as object oriented language. Because actually you will compare dynamic and static typed langauges. The right way is to compare Tcl with Smalltalk, Ruby, Scheme, Python, Self or Tcl object oriented extensions like XOTcl
Quite impresiv is to compare Tcl low level API for C und Java Tcl-Interpreter. The Java API is much more clear and better for understand http://tcljava.sourceforge.net/docs/TclJavaLib/contents.htm There is for example one polymorph method Interpreter.setResult() that accept int, String, doubel and TclObject.
Of course one can write programs without object orientation and you can write bad object oriented programms (Antipattern: Blob, Spagheti Code, Ghost class) especially if one comes from procedural programming.
Another interesting thing is that many systems written in procedural languages build own object oriented systems for structure programm. for example Tix in Tcl or GTK in C. So object orientation is not only the languages but the way how structure programs or think about programing (mental work). Also many Tcl programers use different methods (arrays, namespaces) for build own pseudo object oriented systems. I said "pseudo" because they often does not support all object oriented charcteristic and are "ad hoc" solutions for one application (reinvent the wheel). That make it hard for analyse for another programmer.
Lars H: Two quick remarks. Perhaps someone wants to try refuting them?
CMcC: Advantages: good at representing objects. Disadvantages: not good at representing non-objects. (Next week's topic: advantages and disadvantages of hammers)
KPV: Personally I find oops code can get very hard to read, even well written code. The problem is inheritance and polymorphism.
The problem with inhertance is that if you want to figure out what a given method does, you have to search up the class hierarchy until you find its definition. In a way, inheritance is worse than goto--at least with goto the destination is somewhere in your function but with inheritance it could be in any number of files. The problem with polymorphism means that simply find a function with the right name is not sufficient, you have to also look at the parameters. Trying to read code without a good class browser is almost impossible. It IS impossible once you get into virtual functions where the decision of which function gets called is only determined at runtime.
For example, suppose your trying to figure out the following line of code obj.Write(a);. Which function is being called? Well, if you're lucky and you know what type obj is then you probably only have about 10 different versions of Write() to pick from depending upon what a is. If you're unlucky and obj can be of several types, then you got a lot of work cut out for you.
Two other oops features that can get really hard to read are operator overloading (fortunately it's rarely used), and class properties that look like simple variable assignment but are really complex function calls.
My very first exposure to oops programming was as an intern at Sun Labs (just downstairs from the tcl team) where my job was to instrument C++ kernel code to determine where time was being spent. Kernel programming is hard enough, but the real bear was just trying to read the well-written but deeply inherited code.
ET - Finding this page was like discovering that I really did see the naked emperor. With so much evangelical fervor it’s difficult to trust your own mind. KPV – well done.
Anyhow, I think that objects, if designed very well, can be very useful to the object’s users. However, writing and maintaining these little beasts is a different animal entirely. And code alone is rarely enough to make an object reusable. A good manaul entry and tutorial is a must. I would think that a truly reusable object is 10x more costly to write than a stand alone object.
Also, the temptation to use all the tricks in the bag make something like C++ a nightmare. The best example is the standard template library. To be totally orthogonal (meaning works with everything) some of this code is the most obscure stuff I’ve every seen. And slow as a dog too. I never could create a list of non-primtive objects, and I read a book on the subject. I gave up and crafted my own list code.