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-boun...@delphi.org.nz [mailto:delphi-boun...@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-boun...@delphi.org.nz [mailto:delphi-boun...@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-boun...@delphi.org.nz [mailto:delphi-boun...@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 <lei...@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@delphi.org.nz >> Admin: http://delphi.org.nz/mailman/listinfo/delphi >> Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: >> unsubscribe >> > > _______________________________________________ > NZ Borland Developers Group - Delphi mailing list > Post: delphi@delphi.org.nz > Admin: http://delphi.org.nz/mailman/listinfo/delphi > Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: > unsubscribe > > > _______________________________________________ > NZ Borland Developers Group - Delphi mailing list > Post: delphi@delphi.org.nz > Admin: http://delphi.org.nz/mailman/listinfo/delphi > Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: > unsubscribe > > _______________________________________________ > NZ Borland Developers Group - Delphi mailing list > Post: delphi@delphi.org.nz > Admin: http://delphi.org.nz/mailman/listinfo/delphi > Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: > unsubscribe > > > _______________________________________________ > NZ Borland Developers Group - Delphi mailing list > Post: delphi@delphi.org.nz > Admin: http://delphi.org.nz/mailman/listinfo/delphi > Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: > unsubscribe > _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
