- From: "swansnow" <schultz@xxxxxxxxxxxxxxxxxxxxxxx>
- Date: 25 Aug 2005 07:15:09 -0700
Just wonwdering what "real" programmers do... :)
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?
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)?
2.5) Is a Unit equivalent to a .java file in Java? 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).
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)?
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.
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 :)