D - more power than (really) needed !

[Hasan Aljudy]

Lars Ivar Igesund wrote:
> Hasan Aljudy wrote:
> 
> 
>>I wish the whole world learned object oriented principles from Schock
>>http://pages.cpsc.ucalgary.ca/~schock/courses/w05/cpsc233/lectures.html
> 
> 
> I doubt he is the only lecturer out there to have understood object
> orientation ;)

Yeah .. of course! but I found no resource on the net which can give the 
kind of understaind of oop that he's given me.

> 
> 
>>The problem is when people look at OOP superficially as a set of tools,
>>e.g. inheritance!
> 
> 
> 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 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.


> 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).
You use inheritance when you find that you need to. i.e. when you find 
yourself writing too much duplicate code.

A common *wrong* way for using inheritance, is deciding a class 
hierarchy before doing any kind of analysis for objects.

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