| View previous topic :: View next topic |
| Author |
Message |
Roman Kaßebaum
Guest
|
 Posted: Tue Nov 23, 2004 10:06 am Post subject: naming convention |
 |
|
consider the following:
type
IMyInterface = interface(IInterface)
...
end;
TMyObject = class(TInterfacedObject, IMyInterface)
...
public
//What name is correct?
class function New: IMyInterface;
class function Provide: IMyInterface;
end;
Should I name the class function New, which is a bit like VB, or should
I better name it Provide?
--
Roman
|
|
| Back to top |
|
 |
Lee_Nover
Guest
|
| Posted: Tue Nov 23, 2004 10:14 am Post subject: Re: naming convention |
|
|
| Quote: | Should I name the class function New, which is a bit like VB, or should
I better name it Provide?
|
I prefer: NewInterface
or in the case of:
IPerson = interface(IUnknown) ...
CoPersonFactory = class
class function NewPerson: IPerson;
don't abbreviate the names .. there's no sence and it makes code less
readable .. use full descriptive names :)
|
|
| Back to top |
|
|
Joanna Carter (TeamB)
Guest
|
| Posted: Tue Nov 23, 2004 10:31 am Post subject: Re: naming convention |
|
|
"Roman Kaßebaum" <roman.kassebaumnospam (AT) kdv-dt (DOT) de> a écrit dans le message
de news: [email]41a30b70 (AT) newsgroups (DOT) borland.com[/email]...
| Quote: | Should I name the class function New, which is a bit like VB, or should
I better name it Provide?
|
What is wrong with using the constructor ?
TMyObject = class(TInterfacedObject, IMyInterface)
...
public
constructor Create;
end;
Joanna
--
Joanna Carter (TeamB)
Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker
|
|
| Back to top |
|
|
Joanna Carter (TeamB)
Guest
|
| Posted: Tue Nov 23, 2004 10:36 am Post subject: Re: naming convention |
|
|
"Lee_Nover" <Lee_Nover[nospam]@delphi-si.com> a écrit dans le message de
news: [email]opshwxdqttignj8p (AT) istvangx270 (DOT) vasco.si[/email]...
CoPersonFactory = class
class function NewPerson: IPerson;
This kind of construct is only really necessary for COM or for implementing
the Class Factory pattern.
A constructor is a class function that will return an instance of the given
class. Provided that class supports a given interface, the result of a
constructor is type compatible with a reference to that interface type.
Joanna
--
Joanna Carter (TeamB)
Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker
|
|
| Back to top |
|
|
Roman Kaßebaum
Guest
|
| Posted: Tue Nov 23, 2004 10:49 am Post subject: Re: naming convention |
|
|
Joanna Carter (TeamB) schrieb:
| Quote: | What is wrong with using the constructor ?
TMyObject = class(TInterfacedObject, IMyInterface)
...
public
constructor Create;
end;
|
Using a class function is a little bit better. Normally the class
function works like this:
class function TMyObject.New: IMyObject;
begin
Result := Create;
end;
But one has always the possibility to change it like this:
class function TMyObject.New: IMyObject;
begin
Result := GetClass.Create;
end;
class function TMyObject.GetClass: TMyObjectClass;
begin
Result := //The registered class instead of Self
end;
In another unit, which is specific for a special client, the the new
class is registered:
unit MyObject2;
...
initialization
TMyObject2.RegisterClass;
--
Roman
|
|
| Back to top |
|
|
Lee_Nover
Guest
|
| Posted: Tue Nov 23, 2004 10:49 am Post subject: Re: naming convention |
|
|
| Quote: | CoPersonFactory = class
class function NewPerson: IPerson;
This kind of construct is only really necessary for COM or for
implementing
the Class Factory pattern.
yes .. just demonstrating the naming convention  |
|
|
| Back to top |
|
|
Joanna Carter (TeamB)
Guest
|
| Posted: Tue Nov 23, 2004 10:57 am Post subject: Re: naming convention |
|
|
"Roman Kaßebaum" <roman.kassebaumnospam (AT) kdv-dt (DOT) de> a écrit dans le message
de news: 41a3159a$1 (AT) newsgroups (DOT) borland.com...
| Quote: | Using a class function is a little bit better. Normally the class
function works like this:
class function TMyObject.New: IMyObject;
begin
Result := Create;
end;
snip
But one has always the possibility to change it like this:
|
You could also override NewInstance to achieve the same result.
Joanna
--
Joanna Carter (TeamB)
Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker
|
|
| Back to top |
|
|
Roman Kaßebaum
Guest
|
| Posted: Tue Nov 23, 2004 11:05 am Post subject: Re: naming convention |
|
|
Joanna Carter (TeamB) schrieb:
| Quote: | You could also override NewInstance to achieve the same result.
|
I'm not sure. I think I'll get a recursion if I'll write the following:
class function TMyObject.NewInstance: TObject;
begin
Result := GetClass.NewInstance;
end;
--
Roman
|
|
| Back to top |
|
|
Ritchie Annand
Guest
|
| Posted: Tue Nov 23, 2004 11:34 am Post subject: Re: naming convention |
|
|
Roman Kaßebaum wrote:
| Quote: | type
IMyInterface = interface(IInterface)
...
end;
TMyObject = class(TInterfacedObject, IMyInterface)
...
public
//What name is correct?
class function New: IMyInterface;
class function Provide: IMyInterface;
end;
Should I name the class function New, which is a bit like VB, or should
I better name it Provide?
|
If you're not going to go for a full Factory pattern, then I would suggest
not making it a class function, but instead a regular function.
function NewMyInterface: IMyInterface;
This way, you can completely swap out the base class if you so care to. I do
this with my "guard" classes (function NewGuard: ICOREGuard). I can switch
from my quick TWin32ThreadGuard to my more thorough TDeadlockDetectorGuard
as need be, and they're not inherited from one another.
Not the best pattern in the world, but functional for
swap-a-class-for-the-entire-program cases :)
-- Ritchie Annand
Senior Software Architect
Malibu Software & Engineering Ltd.
Bus. http://www.malibugroup.com
Per. http://nimblebrain.net
|
|
| Back to top |
|
|
Roman Kaßebaum
Guest
|
| Posted: Tue Nov 23, 2004 12:03 pm Post subject: Re: naming convention |
|
|
Roman Kaßebaum schrieb:
| Quote: | class function TMyObject.NewInstance: TObject;
begin
Result := GetClass.NewInstance;
end;
|
Maybe this will work:
class function TMyObject.NewInstance: TObject;
begin
if GetClass = Self then
Result := inherited NewInstance
else
Result := GetClass.NewInstance;
end;
--
Roman
|
|
| Back to top |
|
|
Roman Kaßebaum
Guest
|
| Posted: Tue Nov 23, 2004 1:01 pm Post subject: Re: naming convention |
|
|
Joanna Carter (TeamB) schrieb:
| Quote: | What is wrong with using the constructor ?
TMyObject = class(TInterfacedObject, IMyInterface)
...
public
constructor Create;
end;
|
What about this:
IMyObject = interface(IInterface)
//GUID
procedure DoSomething;
end;
TMyObject = class(TInterfacedObject, IMyObject)
public
procedure DoSomething;
class function New: IMyObject;
end;
with TMyOject.Create do
DoSomething
This will cause a memory leak under win32.
with TMyObject.New do
DoSomething
This will work fine under Win32 and under .net.
--
Roman
|
|
| Back to top |
|
|
Joanna Carter (TeamB)
Guest
|
| Posted: Tue Nov 23, 2004 1:05 pm Post subject: Re: naming convention |
|
|
"Roman Kaßebaum" <roman.kassebaumnospam (AT) kdv-dt (DOT) de> a écrit dans le message
de news: 41a33481$1 (AT) newsgroups (DOT) borland.com...
| Quote: | with TMyOject.Create do
DoSomething
This will cause a memory leak under win32.
|
with is evil, avoid it at all costs )
with TMyObject.Create as IMyObject do
DoSomething
But if you really have to then this is the correct way to do it for Win32
and will also work in .NET
Joanna
--
Joanna Carter (TeamB)
Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker
|
|
| Back to top |
|
|
Lee_Nover
Guest
|
| Posted: Tue Nov 23, 2004 1:20 pm Post subject: Re: naming convention |
|
|
| Quote: | with is evil, avoid it at all costs )
arghhh .. could ppl just stop saying that ! |
| Quote: | with TMyObject.Create as IMyObject do
DoSomething
But if you really have to then this is the correct way to do it for Win32
and will also work in .NET
|
yeah .. that's the proper way ..
|
|
| Back to top |
|
|
Ritchie Annand
Guest
|
| Posted: Wed Nov 24, 2004 10:02 pm Post subject: Re: naming convention |
|
|
In article <41a32c21$1 (AT) newsgroups (DOT) borland.com>,
[email]roman.kassebaumnospam (AT) kdv-dt (DOT) de[/email] says...
| Quote: | This way, you can completely swap out the base class if you so care to. I do
this with my "guard" classes (function NewGuard: ICOREGuard). I can switch
from my quick TWin32ThreadGuard to my more thorough TDeadlockDetectorGuard
as need be, and they're not inherited from one another.
It is the same with a class function. But in the oo-world it would be
better to use a class function.
|
Not true. A class function implies that you are going to use that base
class. This would be appropriate if you were returning a TMyBaseClass,
but not if you were returning an IMyInterface. Interfaces don't specify
a "preferred embodiment".
My Guard classes all implement ICOREGuard, for an example, but they
inherited from TInterfacedObject. Even many of my more complex classes
that *usually* have a base class may have a "mock" class that is just a
plain TInterfacedObject derivative that fakes the services for the
purpose of unit testing.
Cheers :)
-- Ritchie Annand
Senior Software Architect
http://www.malibugroup.com
http://nimble.nimblebrain.net
http://wiki.nimblebrain.net
|
|
| Back to top |
|
|
Roman Kaßebaum
Guest
|
| Posted: Thu Nov 25, 2004 8:29 am Post subject: Re: naming convention |
|
|
Ritchie Annand schrieb:
| Quote: | In article <41a32c21$1 (AT) newsgroups (DOT) borland.com>,
Not true. A class function implies that you are going to use that base
class. This would be appropriate if you were returning a TMyBaseClass,
but not if you were returning an IMyInterface. Interfaces don't specify
a "preferred embodiment".
My Guard classes all implement ICOREGuard, for an example, but they
inherited from TInterfacedObject. Even many of my more complex classes
that *usually* have a base class may have a "mock" class that is just a
plain TInterfacedObject derivative that fakes the services for the
purpose of unit testing.
|
I'm not sure if I understand this correctly: You have a function that
returns an interface. The classes which provide this interface are not
derived from another. Let's see an example:
IGuard = interface(IInterface)
//GUID
....
end;
TObject1 = class(TInterfacedObject, IGuard)
....
end;
TObject2 = class(TInterfacedObject, IGuard)
....
end;
function GetGuard: IGuard
begin
//under special conditions
Result := TObject1.Create
//or under other conditions
Result := TObject2.Create;
end;
In this special case it would be better to use a factory:
TGuardFactory = class(TObject)
public
class function GetGuard: IGuard;
end;
As I already mentioned it is better to use class functions in the
oo-world. Class functions can do all the things that can do normal
functions, but class functions can be overwritten.
In my opinion the .net compiler anyway creates class functions for
normal functions.
--
Roman
|
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
