[DUG] unit source code size

Todd Martin todd.martin.nz at gmail.com
Mon Jul 5 17:49:40 NZST 2010


What do the columns represent in your business logic?
Are you handling every event on every column?

> I am using topgrid. It needs to handle different logic based on which column tsGrid.CurrentCell.DataCol user keyed for KeyDown events. May I ask how to separate the logic to a class?
> 
> Let's say I have ten columns for that grid. I can use case or if statement, but still it is more than 30 lines for that handling logic.
> 
> What is the proper class name for handling that grid function? Call it GridHandlingClass? But this means that business class needs to know form logic. I thought that also break the code maintaince.
> 
> Regards
> Leigh
> 
> -----Original Message-----
> From: delphi-bounces at delphi.org.nz [mailto:delphi-bounces at delphi.org.nz] On Behalf Of Jolyon Smith
> Sent: Monday, 5 July 2010 5:03 p.m.
> To: 'NZ Borland Developers Group - Delphi List'
> Subject: Re: [DUG] unit source code size
> 
> Form units should not usually have methods with 200+ lines.
> 
> Forms should have minimal processing, events typically consisting of a
> handful of lines to invoke business logic on business objects and update the
> UI according to any response.
> 
> There is rarely a 1:1 relationship between any one form and any one business
> object, so if you correctly refactor your business logic into suitable
> business objects I think you will find your problem resolves itself.
> 
> It sounds like the problem here is not Delphi forcing you to have all your
> class source in one unit but rather your having your business logic embedded
> in your UI.
> 
> 
> Hard to say for sure without seeing the source of course.
> 
> 
> -----Original Message-----
> From: delphi-bounces at delphi.org.nz [mailto:delphi-bounces at delphi.org.nz] On
> Behalf Of Leigh Wanstead
> Sent: Monday, 5 July 2010 16:55
> To: NZ Borland Developers Group - Delphi List
> Subject: Re: [DUG] unit source code size
> 
> Hi Colin,
> 
> I am constantly refactoring code, but sometimes the form unit just grows
> bigger and bigger.
> 
> Regards
> Leigh
> -----Original Message-----
> From: delphi-bounces at delphi.org.nz [mailto:delphi-bounces at delphi.org.nz] On
> Behalf Of Colin Johnsun
> Sent: Monday, 5 July 2010 4:39 p.m.
> To: NZ Borland Developers Group - Delphi List
> Subject: Re: [DUG] unit source code size
> 
> Can you refactor your code?
> 
> See if you can break your classes or methods into smaller segments.
> 
> Depending upon your class relationship, can you reduce it to one class per
> unit?
> 
> If you have such large methods (200 lines seems like is a lot!), you
> can break them up into smaller methods.
> 
> If it make sense, you could possibly extract a base class out of your
> existing class and have that in another unit.
> Or rather than extracting out a base class, you can make your classes
> more coherent by redefining them based on their functionality. eg an
> order class that maintains a list of order items, calculates their
> totals and taxes and generates a printed invoice can be broken into
> several smaller (but associated) classes - one for maintaining items,
> one for calculating totals and taxes and another for printing
> invoices.
> 
> Just a thought,
> 
> Colin
> 
> On 5 July 2010 13:50, Leigh Wanstead <leighw at softtech.co.nz> wrote:
>> Good afternoon,
>>
>>
>>
>> I am facing a trouble. Some of the class I wrote reaches more than 1600
>> lines. I don't like it. The methods in the class are ordinary range from
> one
>> line to 200 lines. I really like each method sitting in their own unit.
>>  Just like abap in sap. It is easy to maintain 200 lines in a source code
>> unit than 2000 lines.
>>
>>
>>
>> Without using include, what can I do?
>>
>>
>>
>> BTW, I don't understand why classes.pas in Delphi contain 11103 lines?
> Just
>> to save Delphi programmer less uses clause?
>>
>>
>>
>> TIA
>>
>>
>>
>> Regards
>>
>> Leigh
>>
>> _______________________________________________
>> NZ Borland Developers Group - Delphi mailing list
>> Post: delphi at delphi.org.nz
>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
>> unsubscribe
>>
> 
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at delphi.org.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
> unsubscribe
> 
> 
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at delphi.org.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
> unsubscribe
> 
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at delphi.org.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject: unsubscribe
> 
> 
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at delphi.org.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject: unsubscribe
> 



More information about the Delphi mailing list