class declaration sequence

class declaration sequence

Post by Half Nitt » Sat, 16 Jul 2005 11:19:42


I declared dozens of class in a same unit, the fields of one class may use
the others classes as their data types, for example, FMan in ClassA has
ClassB as its data type, but if the ClassB declared after ClassA, Delphi
would fire a Undeclared identifier exception,the relationships among those
classes might be complex and it would be hard for me to rearrange them in
the same unit. If I declare each class in different units, I doubt the
resulting application would be very large in size, because most of these
classes would read and save data with database, each of them would keep a
copy of ADODB. Are there any other good solutions?
 
 
 

class declaration sequence

Post by Dave Whit » Sat, 16 Jul 2005 12:56:49


I won't discuss your layout, using dozens of classes in one unit. However,
to answer your question, you should declare a forward declaration in the
unit. Look up "Forward declarations and mutually dependent classes" in the
Delphi help file.

type
TFigure = class; // forward declaration

TDrawing = class
Figure: TFigure;
...
end;


TFigure = class // defining declaration
Drawing: TDrawing;
...
end;

 
 
 

class declaration sequence

Post by Team » Sat, 16 Jul 2005 18:42:59


42d71d4c$ XXXX@XXXXX.COM ...


I can't help wondering why you have quite so many classes that have
inter-relationships. Best practice is certainly to have one class per unit
unless there is a *very* close relationship between more than one class, as
in a small hierarchy of derived classes.

Also, it is very bad practice to use fields of any class directly, even in
the same unit.

Can I ask why you feel it necessary to build yourself such a potential
maintenance nightmare ?

Can you post a *short* example of why you need such inter-dependence ?


Declaring classes in separate units does not change the size of an
application, it simply makes life easier with future improvements and
maintenance.

Keeping references to databases in business classes, you could factor out
the database functionality into something like an OPF (Object Persistence
Framework) and avoid any reference to databases in your classes at all.

Joanna

Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker
 
 
 

class declaration sequence

Post by Half Nitt » Sat, 16 Jul 2005 19:39:36

Thank you for your critical suggestions, Joanna.

Actually, I am developing an application to show information with a MS Excel
like sheet. So there might be some classes as TGrid, TCell, TPerson,
TReservation, TFacility, TTeetime and so on. For example, TGird might have a
property Cells[ARow,ACol] to save data into the cell, the value might be
TPerson. Tperson can have TReseration values and etc. All these classes are
related to the TGrid, they are not used by any other classes. So I put them
into the same unit. I know this might not be a good choice and I would like
devide them into seperate units.

I have encapsulate business rules into the SQL stored procedures, all the
classes above would read and save data with ADO Queries or ADO Stored
Procedures in the Datamodule. I am afraid if I put all the functions which
read and save database into a unit, this unit would be much complicated too.