Re: [DUG] unit source code size
Jolyon wrote: Whilst I agree with the rest of your comments about keeping forms and business objects separate - this one caught my attention: This facility was afaik originally created to fix a shortcoming in .NET which was the lack of separate resource files to store form designs (i.e. no DFM's). Form designs were expressed as procedural code to construct the form object controls etc, and thus required an IDE/tool maintained section to be embedded in your application source code. Personally, I don't see this as a shortcoming of .NET - I think it's an improvement. Storing .DFMs as a weakly bytecoded stream of constructors and property assignments in a separate pseudo-interpreter always struck me as a wart of Delphi - something it 'inherited' from VB's design without reconsidering it in the clear light of day. As least they partially saw the light and switched to text .DFMs which are only converted to bytecode at link time. Delphi could have always generated .DFMs as Delphi source code instead which it compiled and included. The advantages to .DFMs being a bytecode interpreted resource format always seemed pretty minimal to me. Frames, form inheritance and other later additions would likely have been a fair bit less awkward and fragile too. So it doesn't surprise me that Anders took the opportunity to revisit that design decision when he designed .NET. Cheers, Paul. ___ 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
Re: [DUG] unit source code size
This is a very interesting topic - I would love to hear others ideas of
organising source for big projects, and any other web references.
My quick thoughts:
Note as far as the Delphi compiler is concerned it is fine with units of
thousands of lines, its still a one pass compiler, and if the IDE can allow
you to jump to declarations of anything and find references it is still very
usable
However in general there are lots of good reasons to separate UI and any
processing code.
I know of two approaches - Model/View/Controller where UI units events all
call business unit functions of business classes in their own class units,
and all data control details are separate in a datamodule.
Less separated is a UI where all event code is either a bit or very
separated from all involved processing logic.
Even detailed and useful UI additional code can be separated from the UI
(example below)
If I have more than a few lines in an event., I instead move the code into a
separate procedure,
eg a button click might look like:
procedure TfrmJBPleditdb.btnSaveCodeClick(Sender: TObject);
begin
SaveCodeDescList;
end;
Depending on what I want to do this routine might either still be in the
form unit, but already can be called by other events on the form- eg from a
DoubleClick. Once it becomes more generally useful I move it into a
library unit and it can be called from anywhere, probably with more
parameters.
Or it could be an action of which the execute method gets called in an
event - this also provides a way of abstracting the functional code from the
UI unit.
Sometimes such abstracted functionality is still just to do with the UI
even, as an alternative way to making descended components - because the
standard VCL components can be used and extra functions can be easily added
to them only when needed down the track. Here is an example which adds a
search facility to any stringgrid.
procedure Tform1.strgrdSearchKeyDown(Sender: TObject; var Key: Word;
Shift: TShiftState);
begin
if (key = $43) and (ssCtrl in Shift) then
begin
CopyThisLine(strgrdSearch); //CTRL+C
end;
if (key = $46) and (ssCtrl in Shift) then
begin
xcGridFind(strgrdSearch,FindStr,strFound);//CTRL+F
end;
if (key = VK_F3) and not (ssShift in Shift) then
begin
xcGridFindNext(strgrdSearch,FindStr,strFound);//F3
end;
if (key = VK_F3) and (ssShift in Shift) then
begin
xcGridFindPrev(strgrdSearch,FindStr,strFound);//Shift+F3
end;
strgrdSearch.setfocus;
end;
The functions (Copythisline, xcGridFind etc) these call are in a library,
which can be anywhere convenient, either in a class definition/business
logic unit or in a standalone code only unit
eg
procedure xcGridFind(pGrid:TStringGrid;var pFindString:String;var
pFound:Boolean);
var
lrow,lcol,rowptr,colptr,lposn:integer;
testcell:string;
begin
lrow:=pGrid.Row;
lcol:=pGrid.Col;
pFindString:=pGrid.Cells[lcol,lrow];//default to current cell contents
pFindString:=inputBox('Find:','Text to find:',pFindString);
pFound:=false;
if pFindstring='' then exit;
for rowptr := lrow+1 to pGrid.rowCount - 1 do
begin
if rowptr= pGrid.RowCount-1 then break;
for colptr := 0 to pGrid.ColCount - 1 do
begin
testcell:=pGrid.Cells[colptr,rowptr];
xcstrin(testcell,pFindstring,lposn,1);//this is a wrapper
for AnsiPos making it non case-sensitive
if lposn0 then
begin
pFound:=true;
break;
end;
end; //col
if pFound=true then break;
end; //row
if pFound then
begin
pGrid.Row:=rowptr;//position at the found cell
pGrid.col:=colptr;
end;
end;
In my case some of these library units might easily be 1 lines+, but its
not an issue either to me or the compiler, I can find stuff easily and the
compiler only compiles and links the functions or procedures required, all
I have to do is add a useful library unit to the uses clause.
John
___
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
Re: [DUG] unit source code size
Thanks everyone for the input. I managed to refractor a unit with source code 1600 lines down to 677 lines by splitting to multiple classes. ;-) Regards Have a nice day 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
[DUG] unit source code size
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
Re: [DUG] unit source code size
In .NET you could use class fragments. .NET (including Prism - the new Delphi for .NET) you can create bits' of a class in separate files. This facility was afaik originally created to fix a shortcoming in .NET which was the lack of separate resource files to store form designs (i.e. no DFM's). Form designs were expressed as procedural code to construct the form object controls etc, and thus required an IDE/tool maintained section to be embedded in your application source code. Class parts were designed to overcome this, allowing the IDE/tool to maintain the form designer code separately from your real code. This of course has since been superceded by XAML etc. Once the genie was out of the bottle, you could of course abuse this to create the maintenance headache and productivity nightmare that you envisage. Or you could, as you suggest, use include files to induce the same nightmare. Ask your team mates about working with source files split across include file fragments if you don't believe that splitting files in this way is A Very Bad Idea (tm). Really, you will create more problems than you will ever solve with such an approach. That is, until the language is invented where this sort of source organisation is intrinsic in the language design. The bubble source model recently demonstrated in Eclipse is a step towards what you have in mind, and as a general principle the idea has some merit, but as I say, whilst a language (it's syntax, compiler and tools etc) is oriented around complete classes contained entirely within a single source file, you really are better off learning the best way to live with that model rather than trying to bash a square peg into a round hole. From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Leigh Wanstead Sent: Monday, 5 July 2010 15:50 To: NZ Borland Developers Group - Delphi List Subject: [DUG] unit source code size 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
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
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
Re: [DUG] unit source code size
It sounds like there is far too much coupling between your classes, if that is the case. 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
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
Re: [DUG] unit source code size
Hi Leigh, On 5 July 2010 14:54, Leigh Wanstead lei...@softtech.co.nz wrote: Hi Colin, I am constantly refactoring code, but sometimes the form unit just grows bigger and bigger. Regards Leigh -Original Message- The amount of code shouldn't bother you. What matters is that the code is in manageable and maintainable chunks. If your form unit is growing then you definitely have a problem of embedding your business code with your UI code. This article isn't strictly about Delphi but it was an inspiration for me with regards to not junking my forms with business code. Its simplistic but the idea behind it is good. The Humble Dialog box www.objectmentor.com/resources/articles/TheHumbleDialogBox.pdf Cheers, Colin ___ 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
Re: [DUG] unit source code size
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
Re: [DUG] unit source code size
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
