D - more power than (really) needed !

[Hasan Aljudy]

Seems like we agree on principles, but we don't agree on what OOP is.

See, you think OOP is a set of tools, when it's actually a set of 
principles.

It's like when you think about books as a set of words rather than a set 
of ideas.
You won't know what's the benefit of writing books or reading them! 
They'd be just a useless set of words!


Lars Ivar Igesund wrote:
> 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 ;) 

I have to disagree! (duh)

> 
> Nothing is as simple as you try to put it. 

I'm *not* trying to make it look simple. It *is* complicated.

> 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.

ok ..

> 
>>>>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!

I'm not promoting inheritance. It's quite the opposite. I'm saying that 
OOP is *not* about inheritance.
Inheritance is just a tool.
Just because your code uses inheritance doesn't mean it's object oriented.
If you don't know how to apply object oriented principles, don't blame 
the paradigm.

When you design your object model, your goal should be to achieve a high 
  level of cohesion and a low level of coupling.

Sometimes you can use inheritance to achieve that goal. Sometimes 
inheritance can stand in your way.

That's why OOP is *not* a set of tools. If you keep thinking about 
object orientation as a set of tools then you will not get much out of it.

> 
> 
>>>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.

See. We agree on principles ;)

> 
> 
>>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.

I'm just trying to change your opinion on OOP. I'm not saying you should 
use it all the time.
I myself don't use OO all the time. I'm not a purist. However, I often 
find myself converting procedural code to OO code, as part of the 
refactoring process.

> 
> 
>>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.

The waterfall method is stupid. I totally agree.

Usually (like I said above), I always find myself converting procedural 
code to object oriented code during the refactoring process.