Re: OOP style

"swansnow" <schultz@xxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1124979309.755732.296890@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> 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?

You can do it either way. If the dialogs are intended simply to
provide information or alerts to the user, I'd use seperate dialogs.

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

Normally you would break down a procedure that was more than a
page in length into several methods. But there are times when
leaving the code together may be necessary. If speed were not an
issue, I'd break the procedure down.

> 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 put the helper methods at the top of the implementation section
(with with one or more comment blocks above them). I place the
main routines at the bottom of the code. Another method would be to
divide the implementation section into logical sub-sections using
comment blocks and place the Save method with the Save helper
functions etc.

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

I don't do Java, but the method I currently prefer is one class per
unit.

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

For small projects, everything goes in the form units. For complex
projects (especially multi-form projects with reuseable code) I prefer
to break the code into seperate units. This generally makes the
project easier to maintain and modify (at least for me).

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

The trick with any system is not to fight it but to go with the sytem flow.
That is, when using Delphi, do things the Delphi way. When using Java,
do things the Java way.

--
Charles Appel
http://charlesappel.home.mindspring.com/
Home of Chuck's Poker Libraries for Delphi,
Chuck's Video Poker and Chuck's Toys


.

Quantcast