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?

If it's a dialog, then I make a dialog. I don't use a panel when I need a dialog, just as I don't use a bicycle when I need a tow truck.

Using a dialog means the dialog's design can be separated from the other form. The dialog can also be used away from the form, either by itself or in conjunction with yet another form. With a dialog, the modal loop is handled for me. If it were just a panel, then I'd need to make special efforts to block access to the rest of the form while the panel was active. Blech.

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

If such a break-down is possible, yes. Especially if those extracted methods could be re-used elsewhere.

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

Generally, I don't. I just use the keyboard to navigate through the unit. Ctrl+Shift+Up toggles between the declaration and the implementation of a routine. With GExperts installed, Ctrl+Alt+Up and Ctrl+Alt+Down take me to the previous and next occurances of an identifier. Ctrl+E lets me do an inline search for an identifier. The Code Explorer is also available, for point-and-click navigation (but I don't use that since it would often stop working in Delphi 5, and I haven't gotten around to trying it now in Delphi 2005).

The necessities of the language -- things need to be declared before they're used -- are about the only organization I do in the implementation section. In the interface section, I alphabetize a class's methods, and the visibility sections are always in the order private, protected, public, published. (I'm having difficulty with Delphi 2005's two new visibilities, strict private and strict protected, since I don't know how to order them relative to private and protected!)

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

No. A unit can have multiple, unrelated classes. To have multiple classes in a single Java source file, they need to be nested classes. A unit can also contain routines that don't belong to any class.

(Incidentally, Delphi 2005 supports nested classes, but not in the same way Java does. Unfortunately, the feature is only half-baked; the compiler allows syntax that suggests nested classes work the way Java's do, but you get errors at run time.)

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

I keep related classes in one file. I'll keep a class, its relevant collection class, and the collection's iterator class, all in one unit, for instance.

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

In my most recent projects, I haven't been involved in the UI enough to worry about that. Usually, I just write classes and library code, and how they get used is someone else's concern. Lucky me.

When I write UI code, it's always for something small enough that it's not worth the time to do much separation. I usually won't take all the logic out of the form class, but on the other hand, I'll often take the logic out of the event handlers, so instead of doing everything in OnClick and OnChange events, those events will make calls to private and protected helper methods with meaningful names. So at least if I ever *do* have to separate the logic from the UI, I'll know exactly where to look.

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


That's a common complaint among people who do OO programming in Delphi.

You might be interested in the borland.public.delphi.oodesign newsgroup on Borland's news servers.

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.

You're free to use such techniques. Delphi doesn't prevent you from doing any of that. It just doesn't make it easy for you all the time, either. Delphi was made 10 years ago for RAD. The whole idea was that you could drop a database connection on your form, drop some DB-aware components on the form, string up some property values, and have the better part of a working application in minutes. You'd press the "play" button and the form you were designing would suddenly become a live program (hence the reason for the poDesigned form-position style). Of course, that's not object-oriented at all.

When you accept the fact that not all development has to be done with components and the Form Designer, you'll write better code. That's partly because you'll actually be _writing_ code instead of just pointing and clicking.

Also remember that every form in your project is a descendant of TForm. Many people don't realize that they can override methods in TForm the same way they can override methods in any other class.

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

If you have Bold (Delphi 7) or ECO (Delphi 2005), then you have some tools for better object-oriented development. They're only available in the expensive editions of Delphi. (I don't have them, so that's all I can tell you about them.) Borland has an ECO-specific newsgroup where you can ask more questions about that.

--
Rob
.

Quantcast