preemptive OOP?

[Mark Elston]

* Kent Johnson wrote (on 9/30/2006 2:04 PM):
> John Salerno wrote:
>> So my question in general is, is it a good idea to default to an OOP 
>> design like my second example when you aren't even sure you will need 
>> it? I know it won't hurt, and is probably smart to do sometimes, but 
>> maybe it also just adds unnecessary code to the program.
> 
> In general, no. I'm a strong believer in You Aren't Going to Need It 
> (YAGNI):
> http://c2.com/xp/YouArentGonnaNeedIt.html
> 
> because it *does* hurt
> - you have to write the code in the first place
> - every time you see a reference to MyNotebook you have to remind 
> yourself that it's just a wx.Notebook
> - anyone else looking at the code has to figure out that MyNotebook is 
> just wx.Notebook, and then wonder if they are missing something subtle 
> because you must have had a reason to create a new class...
> 
> and so on...Putting in extra complexity because you think you will need 
> it later leads to code bloat. It's usually a bad idea.
> 
> Possible exceptions are
> - If you are really, really, really sure you are going to need it 
> really, really soon and it would be much, much easier to add it now then 
> after the next three features go in, then you might consider adding it 
> now. But are you really that good at predicting the future?
> - When you are working in a domain that you are very familiar with and 
> the last six times you did this job, you needed this code, and you have 
> no reason to think this time is any different.
> 
> You struck a nerve here, I have seen so clearly at work the difference 
> between projects that practice YAGNI and those that are designed to meet 
> any possible contingency. It's the difference between running with 
> running shoes on or wet, muddy boots.
> 
> Kent

I have only caught the tail of this thread so far so I may have missed
some important info.  However, Kent's response is, I think, a bit of
an oversimplification.

The answer to the original question, as quoted above, is ... it depends.
On several things, actually.

If this is a 'one-shot' program or simple library to accomplish a
limited goal then the added complexity of OO is probably overkill.  Many
scripts fall into this category. You can go to a lot of trouble to
generate an OO solution to a simple problem and not get much payoff for
your effort.  Simple problems are often solved best with simple
solutions.

However, when an application (or library) is designed to provide a more
'general purpose' solution to one or more problems and is likely to have
a lifetime beyond the 'short term' (whatever that may mean to you), then
OO can start to pay off.  In these kinds of applications you see the
need for future maintenance and a likely need to expand on the existing
solution to add new features or cover new ground.  This is made easier
when the mechanism for this expansion is planned for in advance.

Without this prior planning, any expansion (not to mention bug fixing)
becomes more difficult and makes the resulting code more brittle.  While
not all planning for the future requires OO, this is one mechanism that
can be employed effectively *because* it is generally well understood
and can be readily grasped *if* it is planned and documented well.

There is certainly a *lot* of 'Gratuitous OOP' (GOOP?) out there.  This
isn't a good thing.  However, that doesn't mean that the use of OOP in
any given project is bad.  It may be inappropriate.

OO is a simply a way of dealing with complexity in SW development.  If a
problem is complex then the solution will have to deal with that
complexity.  If OO can be used to make a complex solution less complex
then it is appropriate.  If the use of OO makes a simple solution *more*
complex then it is being used inappropriately.

It is not only necessary to have the correct tools for the job but,
also, to be skilled in their use.  Part of the skill of a SW developer
is in picking the correct tool for the job - and then using it
correctly.

Mark