Re: OOP Design in Delphi using VCL

Pier wrote:
> I am writing an internet application in Delphi 7 and have ended up with a 
> lot of code in the main form's unit file. I make use of many of the events

> of controls on the main form. I want to make the application more modular
so 
> I thought of deriving classes in separate units for some of the controls on

> the main form and overriding methods instead of using events. Is this a
good 
> approach or is there a better way of making the application more modular?

Some suggestions,

1, Put all controls which on the main form to a separate frame, then put 
that frame on the main form. This gives you the chance to add another 
group of controls without modifying current ones' layout.

2, Use TActionList instead of events.

3, By using TActionList, instead of write OnExecute handler for each 
actions, write a handler in TActionList.OnExecute then dispatch the 
event as an ID (use actions' tag property to store the IDs). This is so 
called "command model" in refactoring.
I heavily use this method in my projects. One public project is the 
LeakInspector in Denomo (Google Denomo for it if you want to see the code).
This method will significantly reduce the even handlers count. But it's 
not a must so you may skip this point if you don't know how to implement it.

4, Don't do any business/data logic in the even handlers (hey, the 
handlers belong to UI logic). You need some business/data logic, then 
connect them with the UI through some simple interfaces or APIs.
Your business/data logic module should have the most code instead of the 

Qi wrote:
> 
> Some suggestions,
> 
> 1, Put all controls which on the main form to a separate frame, then put 
> that frame on the main form. This gives you the chance to add another 
> group of controls without modifying current ones' layout.
> 
> 2, Use TActionList instead of events.
> 
> 3, By using TActionList, instead of write OnExecute handler for each 
> actions, write a handler in TActionList.OnExecute then dispatch the 
> event as an ID (use actions' tag property to store the IDs). This is so 
> called "command model" in refactoring.
> I heavily use this method in my projects. One public project is the 
> LeakInspector in Denomo (Google Denomo for it if you want to see the
code).
> This method will significantly reduce the even handlers count. But it's 
> not a must so you may skip this point if you don't know how to implement 
> it.
> 
> 4, Don't do any business/data logic in the even handlers (hey, the 
> handlers belong to UI logic). You need some business/data logic, then 
> connect them with the UI through some simple interfaces or APIs.
> Your business/data logic module should have the most code instead of the 
> UI module.


Sorry for the terrible format (long lines).
I was cheated by ThunderBird that it wrapped the lines virutally