Comparison of Object Oriented Philosophy - Python, Java, C++, Perl
Archive - Originally posted on "The Horse's Mouth" - 2006-08-13 06:24:52 - Graham Ellis
There are two different philosophies that have been adopted by the authors of Object Oriented languages.
The first approach is to set the thing up in such a way that a programmer who uses someone else's code as the basis for his isn't going to be trusted to use that other person's code in a sensible manner. This is the approach taken by languages such as Java and C++, where the programmer who writes the classes / modules that are going to be re-used inserts words like "public", "private" and "protected" all over the code, and declares "virtual functions" or "abstract methods" as appropriate. This forces a user-programmer of the class / module to only make calls that are allowed by his 'supplier' - strict adherance to that person's law is necessary.
The result of this first approach is a system that's pretty cast-iron in what it provides, and it means that even the newest of newcomers to a project isn't going to break an unwritten rule (since the rules are written!!). But at what cost? It's the equivalent of having a policeman at each street corner checking up on everything everyone done ... and yet most of us don't need the incentive of having a policeman on every corner to ensure we don't exceed the speed limit!
Roll out the second approach - taken by Python and Perl. In these languages, the programmer who writes the code that makes use of a base class / package / module from elsewhere is trusted to make sensible use of that base class. It cuts out the need to "public" everything that's to be public. It cuts out the need to define abstract methods. It even cuts out the need to define classes as inheriting from a base class if all that you're looking for is a list of objects that are polymorphic ("have methods of the same name to do the same thing"). Much quicker and easier to code - much more effective - with a big IF ... and that's that it's much more effective IF you can trust your higher level user.
Do you consider yourself to be a "boy racer"? Would you go mad and mow people down as you drive along the road if it wasn't for a covert or overt police presence? Of course you wouldn't! You do things legally, don't you? Perhaps the very occasional compromise at the edges - come on, we've all done something we shouldn't at some time in our life - but basically we're law abiding citizens for the most part, going along with the law and the spirit of what's intended by the law.
And so it is with programming - the vast majority of developers who call up other people's code will abide by the rules set down, even if they're able to break the rules without the compiler stopping them. The vast majority of developers are NOT boy-racers, and any such temptation will in any case be brought to book later on when the person managing the project asks them "why the ****" if something has gone wrong, or they find themselves wasting hours sorting out the side effect of some transgression.
It turns out, then, that the Python and Perl approach of trusting the code re-user makes for much quicker and shorter coding for the original class author, and for the code re-user ... provided that both are reasonably responsible people. And that's typically gooing to be the case. Only where you have code that's going to be re-used by someone who could be considered as a bull in a china shop, or where the stakes of an error are so high as to having mere trust be unacceptable (critical banking, nuclear and defense applications) do you require the policeman-waiting-to-pounce philosophy that's imposed by C++ and Java.