Re: OOP style

"swansnow" <schultz@xxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1124979309.755732.296890@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

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

If it's a dialog, make it a dialog. Please. Having an Execute (or Edit,
or Display) class method in the dialog form class provides very nice
encapsulation. Encapsulation is *important*.


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

Never merely because it's long. If it doesn't break down well, I don't
force it.


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

That's curious. I would sooner have single-line event handlers and
think of other routines as "main" methods.

In the class declaration, visibility order is implicit (published),
private, protected, public, then possibly protected again to put
any methods prescribed by interfaces. I never have an explicit
published section. In the implementation section, visibility classes
are merged.

In form classes, the implicit published section has component fields
and event handlers. In registered component classes, it has properties
and events to be published. Other classes don't have this section.

The private section has property backing fields, Wipe/Init/Setup, and
first-stage (static) property accessors.

The protected section has properties, events, second-stage (virtual)
property accessors, event dispatchers, class methods, other (main!)
methods, and local event handlers.

The public section has constructors, the destructor, and class and
instance methods.

The order in the implementation section is the same but
Ctrl-Shift-Up/Down has made this less pressing.

Component classes have all their main logic in a Custom base class
where most everything is protected, then properties, events, event
dispatchers, and other methods are made public or published later.
Methods, including event dispatchers, require overriding with wrappers
instead of simple redeclaration to make them more visible; this is
unfortunate but I won't declare them public to begin with.


> 2.5) Is a Unit equivalent to a .java file in Java?

Don't know, sorry.


> Generally, do you
> have one class per file? Some of the code I've seen seems to act as
> though a unit is more like a package in Java (several classes stuck
> together in a single file).

Only if they're strongly related. Never two form classes, for example.
But collection and collectionitem classes, always. Component class and
its base (custom) class, always.


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

A form usually starts with everything in it, then things get factored
out. I once abstracted out calculation to a bunch of interfaces and
their reference implementation objects but calculation's mostly been
trivial in my work experience; most larger applications end up with a
database access unit if they didn't already start with a full DB layer;
reporting is definitely outlined always right from the start.

Validation is usually simple in my experience, just a long skip chain
of simple blocks. One example of a method I feel no need to chop up
just because it's long.

My latest application started with an extensively designed object model
and database schema. Several things stand out. You don't appear very
productive while mulling over the design. Producing a lot of paper may
help. Typing in the implementation of the database interface is
exceedingly boring. Writing the implementation of the object model is
less boring and even less fun than the database. Having a well-designed
object model to work with saves *lots* of time writing your user
interface. However, the object model's never well-designed enough not
to need modification, and user interface programming remains a lot of
work.



> I ask, because it seems to me that the way Delphi does things for you
> seems to inhibit proper OOP style.

That's probably partly true. If you start without the right idea of what
to do and how, it's easy to get caught up storing collections in
listboxes and stuffing Tag with too much information everywhere. Better
ways often require more typing, because indeed you're not using many of
the things Delphi wants to do for you.

Could you give some examples? This should be interesting. (-:


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

To find yourself fighting the system is never a good sign. It's usually
worth the investment to find out how the system works and to go with
it. If it's just wrong to begin with (and sometimes it is), ignore it
and use a better system - but be prepared to type it in yourself.

Groetjes,
Maarten Wiltink


.