Re: OOP style

swansnow wrote:
> Just wonwdering what "real" programmers do... :)
>
> Several questions:
> 1) If you have a form, and then some subsidiary dialog boxes, do you
> create separate units for each of those dialogs, or do you make them
> as panels (so thay they're all part of the same unit) that you then
> display when needed?

All RAD-designed dialogs need 1 unit per form class. If more routines
created dialogs from the same form class, I'd let them go in 1 unit.
>
> 2) If you have a procedure that is, say 200 lines long, do you break
> it down in to more modular methods (Extract Method refactoring)? How
> do you organize your unit if you have several "main" methods (like to
> respond to a Save button, and a Load button, and a Preview button) and
> a bunch of "helper" methods (if you have broken down your Save, Load,
> and Preview methods)?

I regularily use nested subroutines, for these reasons:
- Encapsulating a piece of code in a routine means the functionality will
get a name to it, i.e., it is both a way to document and to make code
reading simpler.
- When I am to do a nested for-loop, I prefer to let the inner one go in a
(nested) subroutine.
- ...and to reduce number of code lines, of course...

> 3) When you create a form, do you have a unit which simply validates
> input, and does other UI sorts of things, and then a separate unit
> that handles processing, like calculations, writing to the database,
> or formatting for printing (Model-View pattern)?

No. I kinda separate into units based on the "generality" of the code. I
have an indefinite number of possible "layer distinctions", where the most
general functionality goes into my standard utility units. Thare will also
be code that has no use outside the surrounding routine (aka "nested
subroutine") - made so exactly for that reason - it is of no general
interest.

All projects involve some kinds of general-but-area-specific code, like e.g.
an Excel export unit, or a graph-painting unit/class. Those will be general
and reusable only if you manage to separate tham from the application in a
sensible way.

The code connected to one specific action of this application alone will be
put anywhere. Or, it may be put in specific units due to ease of
documentation, etc..

> I ask, because it seems to me that the way Delphi does things for you
> seems to inhibit proper OOP style. Maybe it's just me, but I find
> myself reverting back to my evil days of spaghetti code, and I feel
> like I fight Delphi at almost every turn. Maintenance is becoming a
> big issue for us, and it seems to me that OOP/refactoring/patterns
> would help in that regard.

The root of all evil, if not avoided, is putting functionality inton event
handler methods of forms. The form classes is a potential anti-OO factor of
Delphi. I tend not to try making them real classes, but rather a
spaghetti-kind of resource that "real" classes either contain or use. There
is a word of wisdom:

"OO stops at the point where you drop your first component on a form".

....a little too bombastic, but very true if not carefully dealt with.

> I'm more familiar with Java, and I've been picking up Delphi over the
> last few months, and the other Delphi programmers I work with have
> kind of picked it up too, so I don't have good OOP role models here :)

I was brought up in ObjectPascal world, but I am now working in a place
where OO is not used at all. To my experience, more important than
differences between productivity and maintainability between the two
doctrines is the fact that they represent very different mindsets. Hence I'm
a poor spaghettiprogrammer and have a hard time convincing about "my" OO's
superiority ;-).
--
Bjørge


.