Posted by Jerry Stuckle on 11/09/07 04:14

lawrence k wrote:
> On Nov 8, 8:38 am, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> lawrence k wrote:
>>> The downside of OOP is that when a new programmer comes in, they've a
>>> harder time figuring out what is going on. Everything is masked and
>>> abstracted. The upside of plain, procedural code is that a new
>>> programmer can usually pick it up faster. This may not be an issue for
>>> you, but for me, being able to hand a project off to other programmers
>>> has been one of my top concerns, so I've come to favor plain code over
>>> OOP.
>> Properly documented, OOP is *much easier* for a new programmer, because
>> he/she doesn't have to worry about the internals. The interface is all
>> that's needed.
>>
>> For instance - do you worry about the internal format of a floating
>> point number? Nope - it's abstracted for you. But you know the
>> interface - and can use them.
>
>
> A floating point number in PHP? Last time I checked PHP was written in
> plain C. It is not written OO anything. If you're trying to say that
> complicated things can be made simple with intelligent masking, then I
> agree with you. But that doesn't have anything to do with OO, does
> it?
>

Yes, it does. All a floating point number is is an object. It has a
state and operations you can perform on it. The only difference is it's
an object provided by the compiler.

> The style one adopts should be well suited to the kinds of clients one
> acquires. I've mostly been working with start-ups where the projects
> start, stop, re-focus, lurch forward in a panic, are canceled, then
> revived, then re-purposed, then declared "ready to launch" about two
> months before I think they are ready to launch. Personally, I never
> get the time to debug any masking code I might write. Buggy code
> hidden under a mask is worse than plain code. The mask simply makes
> debugging harder.
>

Clients don't care about style. They care about results. And proper
design resolves most of these problems, and minimizes the effects of the
others.

Sure, sometimes you have to rewrite code. But a proper OO design limits
the effects of any changes.

And debugging is easier because you can debug and run regression tests
at the class level. Once that's working according to the design, it
won't be a problem in the code.

> If you work on projects that are well-planned and have budgets that
> match the ambition of the project, then I'd say it is best to build
> the code up in layers, with each layer resting on the layer below, and
> each layer well tested before the next higher level is built. And OOP
> is certainly the preferred way to do for such projects.
>

None of the projects I've been on are like that. But every project I've
been on in the last 18 years has built like that. And almost every one
has come in ahead of schedule and under budget. Those which didn't
didn't have a realistic budget or schedule to start with.

It works. And it works better than "code and go".

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[Back to original message]