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.
(written 2006-08-13 06:24:52)
Associated topics are indexed under
C233 - C and C based languages - OO in C++ - beyond the basics [2577] Complete teaching example - C++, inheritance, polymorphism - (2010-01-15)
[1819] Calling base class constructors - (2008-10-03)
[1674] What a lot of files! (C++ / Polymorphism demo) - (2008-06-12)
[1572] C - structs and unions, C++ classes and polymorphism - (2008-03-13)
[1217] What are factory and singleton classes? - (2007-06-04)
[925] C++ - just beyond the basics. More you can do - (2006-11-14)
[801] Simple polymorphism example - C++ - (2006-07-14)
[798] References and Pointers in C++ - (2006-07-10)
C234 - C and C based languages - Further C++ Object Oriented features [2576] What does const mean? C and C++ - (2010-01-15)
[2004] Variable Scope in C++ - (2009-01-22)
[1159] It can take more that one plus one to get two. - (2007-04-22)
[802] undefined reference to typeinfo - C++ error message - (2006-07-15)
J710 - Java - Extending Classes and More [2604] Tips for writing a test program (Ruby / Python / Java) - (2010-01-29)
[2434] Abstract classes, Interfaces, PHP and Java - (2009-10-03)
[2185] Abstract Classes - Java - (2009-05-16)
[1556] Java - a demonstration of inheritance on just one page - (2008-02-26)
[1538] Teaching Object Oriented Java with Students and Ice Cream - (2008-02-12)
[1501] Java - using super to call a method in the parent class - (2008-01-10)
[1294] An example of Java Inheritance from scratch - (2007-08-00)
[1066] Final, Finally and Finalize - three special words in Java - (2007-02-05)
[656] Think about your design even if you don't use full UML - (2006-03-24)
P218 - Perl - More Objects [2651] Calculation within objects - early, last minute, or cached? - (2010-02-26)
[2427] Operator overloading - redefining addition and other Perl tricks - (2009-09-27)
[1949] Nuclear Physics comes to our web site - (2008-12-17)
[1665] Factory method example - Perl - (2008-06-04)
[1664] Example of OO in Perl - (2008-06-03)
[1435] Object Oriented Programming in Perl - Course - (2007-11-18)
[1320] Perl for Larger Projects - Object Oriented Perl - (2007-08-25)
[930] -> , >= and => in Perl - (2006-11-18)
[592] NOT Gone phishing - (2006-02-05)
[588] Changing @INC - where Perl loads its modules - (2006-02-02)
[531] Packages in packages in Perl - (2005-12-16)
[246] When to bless a Perl variable - (2005-03-15)
[227] Bellringing and Programming and Objects and Perl - (2005-02-25)
Q907 - Object Orientation and General technical topics - Object Orientation: Design Techniques [2523] Plan your application before you start - (2009-12-02)
[2501] Simples - (2009-11-12)
[2380] Object Oriented programming - a practical design example - (2009-08-27)
[2327] Planning! - (2009-08-08)
[2170] Designing a heirarcy of classes - getting inheritance right - (2009-05-11)
[2169] When should I use OO techniques? - (2009-05-11)
[1528] Object Oriented Tcl - (2008-02-02)
[1224] Object Relation Mapping (ORM) - (2007-06-09)
[1047] Maintainable code - some positive advice - (2007-01-21)
[836] Build on what you already have with OO - (2006-08-17)
[747] The Fag Packet Design Methodology - (2006-06-06)
[534] Design - one name, one action - (2005-12-19)
[507] Introduction to Object Oriented Programming - (2005-11-27)
[236] Tapping in on resources - (2005-03-05)
[80] OO - real benefits - (2004-10-09)
Y112 - Python - Objects - Intermediate [2485] How do I set up a constant in Python? - (2009-10-31)
[2409] TypeError: super() argument 1 must be type, not classobj (Python) - (2009-09-18)
[2368] Python - fresh examples of all the fundamentals - (2009-08-20)
[1661] Equality, sameness and identity - Python - (2008-05-31)
[1644] Using a utility method to construct objects of different types - Python - (2008-05-17)
[1517] Python - formatting objects - (2008-01-24)
[1146] __new__ v __init__ - python constructor alternatives? - (2007-04-14)
[964] Practical polymorphism in action - (2006-12-04)
[903] Pieces of Python - (2006-10-23)
[477] Class, static and unbound variables - (2005-10-25)
[383] Overloading of operators on standard objects in Python - (2005-07-19)
[296] Using a Python dictionary as a holder of object attributes - (2005-04-30)
Some other Articles
Python - when to use the in operatorPython makes University ChallengeOld Wardour CastleDisplaying data at 5 items per line on a web pageComparison of Object Oriented Philosophy - Python, Java, C++, PerlButterflies in a Wiltshire gardenWhere to go within 30 minutes of MelkshamFreedom of speech and freedom to postNo news is good news with Unix and LinuxFighting illegal net use by imposing download limits