D - more power than (really) needed !

[Lars Ivar Igesund]

Hasan Aljudy wrote:
>> 
>> OOP _is_ a set of tools. Nothing more, nothing less.
> 
> no my friend, it's alot more!
> oop is a way of thinking (in terms of coding, of course). It's a
> different way of doing analysis and design.
> Object oriented analysis and design produce completely different results
> from procedural analysis and design.
> 
> You can do procedural analysis and design but write code that uses
> classes and employes inheritance, but your code will still be
> procedural, because when you thought about the problem you did so
> procedurally, and the code will inevitable reflect that.

OOP is a toolbox in a programming toolshed (and inheritance is a tool in
that particular toolbox). Just to make this great analogy complete ;) 

Nothing is as simple as you try to put it. When analyzing/designing, you
should create structures, objects and functions so they reflect the
topology of the problem at hand. It IS wrong to decide which tool to use
before you know the problem. But of course one know how to use some tools
better than others, and this will reflect the way one works.

> 
>>>OOP is not a set of tools, it's a set of principles. Inheritance is not
>>>there just for the sake of it, it serves a very good purpose: increasing
>>>cohesion by pulling common/shared code in a super class.
>> 
>> 
>> Yes, and by this you get tight coupling and reduced reusability and
>> extendability.
> 
> If that happens, it generally means you don't know what you're doing;
> you're using inheritance the wrong way.

One can be lucky, but usually strong cohesion reduce flexibility. Using
inheritance in all cases is the wrong way, use it where it helps toward a
solution!

> 
>> Principles just get in the way for practicality. Using
>> inheritance just for the sake of it, or because of principles, is nothing
>> even close to practical.
> 
> You don't use inheritance because it's a principle (that's the same as
> using just for its own sake).

Yes, which is what I said.

> You use inheritance when you find that you need to. i.e. when you find
> yourself writing too much duplicate code.

Yes, I'm glad you agree. And usually you need very little inheritance, even
though you might program everything using objects, either it is to
encapsulate state, functionality or resources.

>> But then my programming principles encompass pragmatism :)
> 
> Funny you should say so.
> 
> Is skipping the analysis and design phases (i.e. diving right into
> writing code) pragmatic or not?

Of course not, I've never said that. In your previous posts you have
preached the view that we should use OOP (and with it inheritance), and
that there never is a need to use anything else. I am just politely
disagreeing with you.

> You can say it's pragmatic .. if you're too lazy to do it! However,
> you'll actually get the most out of your time if you do a proper
> analysis and design first.

You might get an even better result if you analyze, design and implement
(and refactor) continuosly to get a better understanding of the system and
problems at hand, and some OOP ways to do things (especially inheritance)
make this difficult. The waterfall method is a software engineering
fossile.