Factory methods is the way to go. Personally, I prefer to use factory classes (actually factory interfaces). You certainly don't want to limit your design to inherit all implementation classes from the same base class, though, sometimes, it can be helpful to have an abstract base class that implements some of the common methods of the interface.
As for your form, you can use an adapter class that inherits from TInterfacedObject. Take a look at TStreamAdapter for an example. Dennis. ----- Original Message ----- From: "Trevor Jones" <[EMAIL PROTECTED]> To: "Multiple recipients of list delphi" <[EMAIL PROTECTED]> Sent: Thursday, August 08, 2002 1:11 PM Subject: Re: [DUG]: Interfaces (and classes that support them) > Phil, > Thanks for the idea, but it kinda breaks the idea of an Interface being > supported by *ANY* class type. In some cases the objects that support the > interfaces I'm using are subclassed from TInterfacedObject, other times they > may be components or even forms. As luck would have it, a TForm does not > subclass TInterfacedObject, so this stops me using this approach. > > > For the moment, I've opted to register factory functions rather than the > classes themselves and this seems to cover most issues. > > Trevor > > ----- Original Message ----- > From: "Phil Middlemiss" <[EMAIL PROTECTED]> > To: "Multiple recipients of list delphi" <[EMAIL PROTECTED]> > Sent: Thursday, August 08, 2002 8:34 AM > Subject: Re: [DUG]: Interfaces (and classes that support them) > > > > Trevor, > > > > I usually create a simple base class with a virtual constructor that I > then > > descend from where appropriate. > > > > eg. > > TMyObject = class(TInterfacedObject) > > public > > constructor Create; virtual; > > end; > > > > TMyObjectClass = class of TMyObject; > > > > Now everything that needs to can descend from TMyObject, and the > > MyInterfaceClass function uses the variables > > > > AClass: TMyObjectClass; > > AObject: TMyObject; > > > > This assumes, of course, that you have control over which classes are > used. > > > > Kind regards, > > > > Phil. > > > > ----- Original Message ----- > > From: "Trevor Jones" <[EMAIL PROTECTED]> > > To: "Multiple recipients of list delphi" <[EMAIL PROTECTED]> > > Sent: Wednesday, August 07, 2002 5:03 PM > > Subject: [DUG]: Interfaces (and classes that support them) > > > > > > > Hi all, > > > One of the things that I like about using Interfaces is that the > classes > > > supporting them can be of any type - Yeeha! > > > > > > However it can be tricky deciding how to construct an object from just a > > > class reference that supports an interface because the TObject > constructor > > > is not virtual. > > > > > > My solutions so far amount to stuff like this (where the last registered > > > class is the one to be created): > > > > > > var > > > List : TList; > > > > > > procedure RegisterMyInterfacedClass(aClass : TClass); > > > begin > > > if supports(aClass,IMyInterface) then > > > List.Add(aClass); > > > end; > > > > > > procedure UnRegisterMyInterfacedClass(aClass : TClass); > > > var > > > i : integer; > > > begin > > > i := List.IndexOf(aClass); > > > if i >= 0 then > > > List.Delete(i); > > > end; > > > > > > function MyInterfacedClass : IMyInterface; > > > var > > > aClass : TClass; > > > aObject : TObject; > > > begin > > > result := nil; > > > if List.Count > 0 then > > > begin > > > aClass := List[List.count-1]; > > > if aClass.inheritsFrom(TComponent) then > > > aObject := TComponentClass(aClass).create(application) > > > else > > > aObject := TClass.create; > > > // Supports should always be true here, its just an easy way to get > > the > > > interface > > > if not Supports(aObject, IMyInterface,result) then > > > aObject.free; > > > end; > > > end; > > > > > > > > > All of this nonsense seems to work very well at the moment, but I'm > unsure > > > how safe it is. > > > > > > The gotchas seem to be: > > > If the class inherits only from TInterfacedObject, its specific > > > constructor is not called, the class must override AfterConstruction to > > > create any needed bits (like stringlists etc.). > > > > > > If the class uses some fancy constructor that requires something other > > > than an owner, then I'm stuck. > > > > > > Does anyone have a more elegant way of going about this that they are > > > willing to share? > > > > > > Trevor > > > > > > > > > > > > > > > > -------------------------------------------------------------------------- > > - > > > New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] > > > Website: http://www.delphi.org.nz > > > To UnSub, send email to: [EMAIL PROTECTED] > > > with body of "unsubscribe delphi" > > > Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/ > > > > > > > > > -------------------------------------------------------------------------- > - > > New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] > > Website: http://www.delphi.org.nz > > To UnSub, send email to: [EMAIL PROTECTED] > > with body of "unsubscribe delphi" > > Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/ > > > > > > > -------------------------------------------------------------------------- - > New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] > Website: http://www.delphi.org.nz > To UnSub, send email to: [EMAIL PROTECTED] > with body of "unsubscribe delphi" > Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/ > --------------------------------------------------------------------------- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz To UnSub, send email to: [EMAIL PROTECTED] with body of "unsubscribe delphi" Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
