Posted by Ben C on 10/07/07 14:27

On 2007-10-07, Jerry Stuckle <jstucklex@attglobal.net> wrote:
> Ben C wrote:
[...]
>> One might say well that's just bad OO programming, not OO programming in
>> general. But that's a cop-out-- the real question is how hard or easy is
>> it to do good or bad OO programming.
>>
>
> It's bad OO design. It is easy to do good OO programming, with the
> right training and experience.

I can believe you in theory, but I've never actually seen any good OO
programming, and lot of bad OO programming. Where does this training
come from? Who has this experience?

Name a good open source OO-designed program and I will gladly have a
look at it and be prepared to learn something.

>> OO can encourage people to make too many design decisions up-front,
>> before they really know what they want to do yet.
>>
>
> Good design (not just OO) dictates that your decisions MUST be made up
> front.

For houses, yes, not for programs.

> Can you imagine creating the blueprints after the house is 1/2 built?
> But that's how a lot of people approach programming problems.

Indeed, and many programming problems are better approached that way.

>> It's supposed to protect against dreaded type mismatch errors-- you pass
>> the wrong type of object to a function by mistake-- but how often do
>> such errors actually really happen?
>>
> Nothing in OO protects against type mismatch errors. That is completely
> dependent on how strict the language's type checking is. PASCAL, for
> instance, is a non-OO language, but does not allow any type mismatches.

OK, yes, OO and strict type checking are different things, and you can
have either without the other.

[Back to original message]