[Tutor] RE: when to use OOP

[Dan Shafer]

Probably a minority view.

I think that designing and programming software that goes beyond the fairly 
trivial should always be an occasion to consider seriously using OOP 
techniques. I am a strong advocate of OOP for almost any application that 
isn't just a toy demo app, in fact.

There are lots of reasons for this and the case for OOP has been more than 
adequately made by far smarter people than I. But I have one reason for 
recommending that this virtually *always* be the strategy that is only sort 
of touched on by other advocates.

I have found in many, many years of programming everything from relatively 
trivial and focused examples for some of my books to large-scale systems 
that I seldom if ever have a really keen view of what the software will 
ultimately want to be or become. Users change their minds (even when the 
user is me and I'm writing what feels at first like a trivial application). 
Specs and needs change. Potential add-ons and features that could not occur 
to someone before seeing the first cut at an application become must-haves.

As a result, code -- even code you think is small, single-purpose, and 
static and therefore not necessarily a good candidate for OOP -- morphs 
over time. I have found it invariably to be true that when I need to extend 
or enhance software, having OOP code makes that process easier, faster, 
more effective, and far less bug-prone. This is a subset of the major 
argument for OOP that involves the whole issue of code maintenance; I just 
extend it to include code that at first blush seems not to call for OOP.

There is no doubt OOP takes longer in the design stage (at least most of 
the time) over the more traditional jump-in-and-code approach many coders 
writing smallish things tend to take (myself included). And there is no 
doubt that there is some overhead associated with OOP design and coding. 
But I have never seen the end result prove unworthy of the additional time 
and overhead.

So my advice is not to look for a reason to use OOP but rather to start 
every project with the assumption that OOP is in order and only deviate 
from that decision when clear circumstances dictate. I've never seen a 
project that was harder to extend or maintain because it was built using 
OOP strategies and techniques.

Dan Shafer, Chief Scribe and Tablet Keeper
PythonCard Open Source Project
http://pythoncard.sourceforge.net