I note some discussion in other Delphi blogs about what is and is not good object oriented design. It seems to me that answering this question requires going back to first principles: Why should we bother with object orientation at all? Do we do this to be buzzword-compliant, or are there real advantages to the technique? That, it seems to me, is the key to understanding otherwise-abstract concepts such as polymorphism, and other things which confuse the heck out of folks new to the field.
I’ve been meaning to write about this for some time, but have never had time to put my thoughts together. So I’ve decided to build the article one section at a time, in public, using the same "release early principle for the article that I try to use for my software.
So here’s the first section. Your comments — especially if you are new to or confused by object oriented design — are welcome.
{ 2 } Comments
the most important think is :
reusibility
then :
extedibility
so oo design mean to separate between class user and class writer
———–
orwah issa
Object orientation in Delphi is mainly procedural programming with SELF being passed as a hidden parameter and a few other /syntactic sugars/ going on under the hood.
Enough syntactic sugars to make it worthwhile. You can really have code reuse go on with procedural code to - it just gets messy because you have to pass in more parameters into the procedures. With OO code, it hides the self paramater and the get/set properties are hidden using the assign := operator.
Inhertance? again, it can be done in procedural code by reusing subprocedures - just that OO tidies it up and makes it neater.
Post a Comment