Home Accessibility Courses Diary The Mouth Forum Resources Site Map About Us Contact
Comparison of Object Oriented Philosophy - Python, Java, C++, Perl

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)


Back to
Butterflies in a Wiltshire garden
Previous and next
or
Horse's mouth home
Forward to
Displaying data at 5 items per line on a web page
Some other Articles
Python - when to use the in operator
Python makes University Challenge
Old Wardour Castle
Displaying data at 5 items per line on a web page
Comparison of Object Oriented Philosophy - Python, Java, C++, Perl
Butterflies in a Wiltshire garden
Where to go within 30 minutes of Melksham
Freedom of speech and freedom to post
No news is good news with Unix and Linux
Fighting illegal net use by imposing download limits
2660 posts, page by page
Link to page ... 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54 at 50 posts per page


This is a page archived from The Horse's Mouth at http://www.wellho.net/horse/ - the diary and writings of Graham Ellis. Every attempt was made to provide current information at the time the page was written, but things do move forward in our business - new software releases, price changes, new techniques. Please check back via our main site for current courses, prices, versions, etc - any mention of a price in "The Horse's Mouth" cannot be taken as an offer to supply at that price.

Link to Ezine home page (for reading).
Link to Blogging home page (to add comments).

You can Add a comment or ranking to this page

© WELL HOUSE CONSULTANTS LTD., 2010: Well House Manor • 48 Spa Road • Melksham, Wiltshire • United Kingdom • SN12 7NY
PH: 01144 1225 708225 • FAX: 01144 1225 344596 • EMAIL: info@wellho.net • WEB: http://www.wellho.net • SKYPE: wellho