| View previous topic :: View next topic |
| Author |
Message |
Brad White
Guest
|
 Posted: Wed Oct 29, 2003 9:29 pm Post subject: singleton initialization |
 |
|
Normally I would have a singleton created
in initialization and destroyed in final;
or created on-demand and destroyed
in finalization.
But what do I do when it needs some initialization?
For instance if it needs to be fed a DataProvider,
since it doesn't know about the DataModule.
Should I change the 'ownership' responsibilities
to a master controller that creates and initializes
and holds the reference to the singleton.
Or should the master controller just initialize
self-existent singletons?
--
Thanks,
Brad White
|
|
| Back to top |
|
 |
John Elrick
Guest
|
| Posted: Thu Oct 30, 2003 12:48 am Post subject: Re: singleton initialization |
|
|
"Brad White" <bwhite at inebraska.com> wrote
| Quote: | Normally I would have a singleton created
in initialization and destroyed in final;
or created on-demand and destroyed
in finalization.
But what do I do when it needs some initialization?
For instance if it needs to be fed a DataProvider,
since it doesn't know about the DataModule.
Should I change the 'ownership' responsibilities
to a master controller that creates and initializes
and holds the reference to the singleton.
Or should the master controller just initialize
self-existent singletons?
|
One solution is to have a registration unit, whose sole job it is to set up
stuff like that.
I've found it useful to set up abstract factories.
John
|
|
| Back to top |
|
|
Lawrence Thurman
Guest
|
| Posted: Thu Oct 30, 2003 5:02 pm Post subject: Re: singleton initialization |
|
|
| Quote: | One solution is to have a registration unit, whose sole job it is to set
up
stuff like that.
|
Yeah but that does nothing to prevent another developer from calling create
which means you
have to have a contract for the singleton.
Override the NewInstance - see my post and singleton references
Lawrence
|
|
| Back to top |
|
|
John Elrick
Guest
|
| Posted: Thu Oct 30, 2003 10:28 pm Post subject: Re: singleton initialization |
|
|
"Lawrence Thurman" <lawrence (AT) powerofzen (DOT) com> wrote
| Quote: | One solution is to have a registration unit, whose sole job it is to set
up
stuff like that.
Yeah but that does nothing to prevent another developer from calling
create
which means you
have to have a contract for the singleton.
Override the NewInstance - see my post and singleton references
|
In the below, FooFactory is the Singleton. It is totally abstract and can
be reimplemented without even changing uses clauses in all but one unit.
There is simply no way for Create to ever even be called.
unit uintf_MyStuff;
interface
type
IFoo = interface
end;
IFooFactory = interface
function makeNew : IFoo;
end;
CFooFactoryManager = class
class procedure InitializeFactory(const aFooFactory: IFooFactory);
end;
function FooFactory: IFooFactory;
implemenation
var
Singleton : IFooFactory = nil;
....
end.
--------------
unit uMyStuffImpl;
interface
uses uintf_MyStuff;
implementation
TFoo = ...
TFooFactory = ...
initialization
CFooFactoryManager.InitializeFactory(TFooFactory.Create);
end.
--------------
unit registration
implementation
uses
uMyStuffImpl,
...
end.
John
|
|
| Back to top |
|
|
Lawrence Thurman
Guest
|
| Posted: Fri Oct 31, 2003 3:17 pm Post subject: Re: singleton initialization |
|
|
So are you saying with this implementation that I could not say
uses
uintf_MyStuff;
....
....
var
ACFooFactoryManager : CFooFactoryManager;
begin
ACFooFactoryManager := CFooFactoryManager .Create;
end;
Why not?
"John Elrick" <jelrick (AT) adelphia (DOT) net> wrote
| Quote: |
"Lawrence Thurman" <lawrence (AT) powerofzen (DOT) com> wrote in message
news:3fa14408$1 (AT) newsgroups (DOT) borland.com...
One solution is to have a registration unit, whose sole job it is to
set
up
stuff like that.
Yeah but that does nothing to prevent another developer from calling
create
which means you
have to have a contract for the singleton.
Override the NewInstance - see my post and singleton references
In the below, FooFactory is the Singleton. It is totally abstract and can
be reimplemented without even changing uses clauses in all but one unit.
There is simply no way for Create to ever even be called.
unit uintf_MyStuff;
interface
type
IFoo = interface
end;
IFooFactory = interface
function makeNew : IFoo;
end;
CFooFactoryManager = class
class procedure InitializeFactory(const aFooFactory: IFooFactory);
end;
function FooFactory: IFooFactory;
implemenation
var
Singleton : IFooFactory = nil;
...
end.
--------------
unit uMyStuffImpl;
interface
uses uintf_MyStuff;
implementation
TFoo = ...
TFooFactory = ...
initialization
CFooFactoryManager.InitializeFactory(TFooFactory.Create);
end.
--------------
unit registration
implementation
uses
uMyStuffImpl,
...
end.
John
|
|
|
| Back to top |
|
|
Brad White
Guest
|
| Posted: Fri Oct 31, 2003 10:41 pm Post subject: Re: singleton initialization |
|
|
| Quote: | "John Elrick" <jelrick (AT) adelphia (DOT) net> wrote
In the below, FooFactory is the Singleton. It is totally abstract and
can
be reimplemented without even changing uses clauses in all but one unit.
There is simply no way for Create to ever even be called.
"Lawrence Thurman" <lawrence (AT) powerofzen (DOT) com> wrote |
| Quote: | So are you saying with this implementation that I could not say
begin
ACFooFactoryManager := CFooFactoryManager .Create;
end;
Why not?
No he's not. |
As he said, FooFactory is the singleton. Not the manager.
--
HTH,
Brad White
|
|
| Back to top |
|
|
John Elrick
Guest
|
| Posted: Mon Nov 03, 2003 2:05 pm Post subject: Re: singleton initialization |
|
|
"Lawrence Thurman" <lawrence (AT) powerofzen (DOT) com> wrote
| Quote: | So are you saying with this implementation that I could not say
uses
uintf_MyStuff;
...
...
var
ACFooFactoryManager : CFooFactoryManager;
begin
ACFooFactoryManager := CFooFactoryManager .Create;
end;
Why not?
|
Of course you can...that's the manager class. If you instanciate the
manager class, you're in a lot more trouble than a simple NewInstance
override can fix...it shows total lack of understanding of the code base and
system.
However, it also does no harm<g>
John
|
|
| Back to top |
|
|
Lawrence Thurman
Guest
|
| Posted: Mon Nov 03, 2003 2:31 pm Post subject: Re: singleton initialization |
|
|
John,
They way I am reading this is that there is a contract that needs to be
upheld in order to not create to the Singleton instance.
Which IMHO is not a true singleton.
Lawrence
"John Elrick" <jelrick (AT) adelphia (DOT) net> wrote
| Quote: |
"Lawrence Thurman" <lawrence (AT) powerofzen (DOT) com> wrote in message
news:3fa27ce1 (AT) newsgroups (DOT) borland.com...
So are you saying with this implementation that I could not say
uses
uintf_MyStuff;
...
...
var
ACFooFactoryManager : CFooFactoryManager;
begin
ACFooFactoryManager := CFooFactoryManager .Create;
end;
Why not?
Of course you can...that's the manager class. If you instanciate the
manager class, you're in a lot more trouble than a simple NewInstance
override can fix...it shows total lack of understanding of the code base
and
system.
However, it also does no harm
John
|
|
|
| Back to top |
|
|
Bryan Crotaz
Guest
|
| Posted: Mon Nov 03, 2003 2:33 pm Post subject: Re: singleton initialization |
|
|
Your naming makes it hard to follow - I would assume that a FooFactory is
responsible for creating Foos, so Foo should be the singleton.
However I can see what you've done - but what's the point of a class with a
single class method? Why not just a plain function?
The way I do this is to create EVERYTHING through a factory. Each dll has a
single exported function returning an interface to its factory. Some dlls
have normal factories, others have singleton factories, where a list of
supplied objects is held. When a class instance is requested it iterates
that list and if it finds one of the requested class it returns it,
otherwise it creates a new one and adds it to the list, then returns it.
Bryan
|
|
| Back to top |
|
|
John Elrick
Guest
|
| Posted: Mon Nov 03, 2003 4:11 pm Post subject: Re: singleton initialization |
|
|
"Lawrence Thurman" <newsgroup1 (AT) powerofzen (DOT) com> wrote
| Quote: | John,
They way I am reading this is that there is a contract that needs to be
upheld in order to not create to the Singleton instance.
Which IMHO is not a true singleton.
|
There is nothing in literature that defines a Singleton as a concrete class
reference.
I'm afraid I'm not following this sentence:
They way I am reading this is that there is a contract that needs to be
upheld in order to not create to the Singleton instance.
Do you mean "there is a contract that needs to be upheld in order to create
the Singleton instance"
This example describes an Abstract Singleton, which of course must have its
factory initialized. The Factory is then responsible for how many instances
are to be created (one or many) as well as the implementation.
John
|
|
| Back to top |
|
|
John Elrick
Guest
|
| Posted: Mon Nov 03, 2003 4:14 pm Post subject: Re: singleton initialization |
|
|
"Bryan Crotaz" <bryan (AT) no (DOT) spam.for.me.please.inspirationmatters.com> wrote in
message news:3fa667a1 (AT) newsgroups (DOT) borland.com...
| Quote: | Your naming makes it hard to follow - I would assume that a FooFactory is
responsible for creating Foos, so Foo should be the singleton.
|
Foo can be a Singleton. The FooFactory approach means that the consumer is
totally unaware of whether we are dealing with a Singleton or not.
| Quote: |
However I can see what you've done - but what's the point of a class with
a
single class method? Why not just a plain function?
|
FooFactory _is_ a function. I don't follow.
AFA the CFooFactoryManager...this is a legitimate class. It is perfectly
valid for a class to have a single responsibility.
John
|
|
| Back to top |
|
|
Lawrence Thurman
Guest
|
| Posted: Mon Nov 03, 2003 5:49 pm Post subject: Re: singleton initialization |
|
|
| Quote: | This example describes an Abstract Singleton, which of course must have
its
factory initialized. The Factory is then responsible for how many
instances
are to be created (one or many) as well as the implementation.
|
I agree with you that it is an abstract factory.
| Quote: | There is nothing in literature that defines a Singleton as a concrete
class
reference.
|
Here is how the Gang of Four define it in Design Patterns.
A class itself is responsible for keeping track of its sole instance. The
class can ensure
that no other instance can be created (by intercepting requests to create
new objects), and it can provide a way
to access the instance.
"John Elrick" <jelrick (AT) adelphia (DOT) net> wrote
| Quote: |
"Lawrence Thurman" <newsgroup1 (AT) powerofzen (DOT) com> wrote in message
news:3fa6669a$1 (AT) newsgroups (DOT) borland.com...
John,
They way I am reading this is that there is a contract that needs to
be
upheld in order to not create to the Singleton instance.
Which IMHO is not a true singleton.
There is nothing in literature that defines a Singleton as a concrete
class
reference.
I'm afraid I'm not following this sentence:
They way I am reading this is that there is a contract that needs to be
upheld in order to not create to the Singleton instance.
Do you mean "there is a contract that needs to be upheld in order to
create
the Singleton instance"
This example describes an Abstract Singleton, which of course must have
its
factory initialized. The Factory is then responsible for how many
instances
are to be created (one or many) as well as the implementation.
John
|
|
|
| Back to top |
|
|
Bryan Crotaz
Guest
|
| Posted: Mon Nov 03, 2003 11:41 pm Post subject: Re: singleton initialization |
|
|
"John Elrick" <jelrick (AT) adelphia (DOT) net> wrote
| Quote: |
"Bryan Crotaz" <bryan (AT) no (DOT) spam.for.me.please.inspirationmatters.com> wrote
in
message news:3fa667a1 (AT) newsgroups (DOT) borland.com...
Your naming makes it hard to follow - I would assume that a FooFactory
is
responsible for creating Foos, so Foo should be the singleton.
Foo can be a Singleton. The FooFactory approach means that the consumer
is
totally unaware of whether we are dealing with a Singleton or not.
|
But you have a Foo, a FooFactory and a FooFactoryManager - one level of
complexity too much for a simple example. All I'm saying is it's not
obvious what does what from your naming scheme.
| Quote: | FooFactory _is_ a function. I don't follow.
AFA the CFooFactoryManager...this is a legitimate class. It is perfectly
valid for a class to have a single responsibility.
|
CFooFactoryManager = class
class procedure InitializeFactory(const aFooFactory: IFooFactory);
end;
Why not just
implementation
procedure InitializeFactory(const aFooFactory: IFooFactory);
begin
Do stuff;
end;
?
I agree that the class approach will compile fine, but what's the point,
where's the advantage over a simple function? If the singleton storage was
inside the class I could see the point, but it's not - and as the class
never gets instantiated, it can't be....
Bryan
|
|
| Back to top |
|
|
John Elrick
Guest
|
| Posted: Mon Nov 03, 2003 11:54 pm Post subject: Re: singleton initialization |
|
|
"Bryan Crotaz" <bryan (AT) no (DOT) spam.for.me.please.inspirationmatters.com> wrote in
message news:3fa6e7e8$1 (AT) newsgroups (DOT) borland.com...
| Quote: |
"John Elrick" <jelrick (AT) adelphia (DOT) net> wrote in message
news:3fa67f03$1 (AT) newsgroups (DOT) borland.com...
"Bryan Crotaz" <bryan (AT) no (DOT) spam.for.me.please.inspirationmatters.com
wrote
in
message news:3fa667a1 (AT) newsgroups (DOT) borland.com...
Your naming makes it hard to follow - I would assume that a FooFactory
is
responsible for creating Foos, so Foo should be the singleton.
Foo can be a Singleton. The FooFactory approach means that the consumer
is
totally unaware of whether we are dealing with a Singleton or not.
But you have a Foo, a FooFactory and a FooFactoryManager - one level of
complexity too much for a simple example. All I'm saying is it's not
obvious what does what from your naming scheme.
|
Well...Foo makes it that much harder
IPrinter
procedure print;
end;
IPrinterFactory
end;
CPrinterFactoryManager
| Quote: |
FooFactory _is_ a function. I don't follow.
AFA the CFooFactoryManager...this is a legitimate class. It is
perfectly
valid for a class to have a single responsibility.
CFooFactoryManager = class
class procedure InitializeFactory(const aFooFactory: IFooFactory);
end;
Why not just
implementation
procedure InitializeFactory(const aFooFactory: IFooFactory);
begin
Do stuff;
end;
|
You can do that. Personal preference.
John
|
|
| Back to top |
|
|
John Elrick
Guest
|
| Posted: Tue Nov 04, 2003 12:16 am Post subject: Re: singleton initialization |
|
|
"Lawrence Thurman" <newsgroup1 (AT) powerofzen (DOT) com> wrote
| Quote: | This example describes an Abstract Singleton, which of course must have
its
factory initialized. The Factory is then responsible for how many
instances
are to be created (one or many) as well as the implementation.
I agree with you that it is an abstract factory.
There is nothing in literature that defines a Singleton as a concrete
class
reference.
Here is how the Gang of Four define it in Design Patterns.
|
"Ensure a class only has one instance, and provide a global point of access
to it"
I have the book also.
Please note...there is nothing "wrong" with your approach. It's perfectly
valid. I prefer the Abstract Singleton approach.
John
|
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
