Inheritance of a singleton class

[Marcel Hug]

Hallo NG !
I Have a little question about inheritance of a singleton class.
In my application i have a Database-Connection Lib, in which I would ¨like
to connect different databases of the same project (thats why it is in a
lib).
For the database A I created a singleton class AProxy and for the database B
the same as BProxy. Initializing and connetcing to the Database is the same
in both classes (except of the database-path, which is a parameter), just
the Functions are different, because the tables are different.
Now I thought about creating a general DBConnectifity-class (or interface)
to generalize the Initializing and db-connection stuff in this class and
define the specific function in the suc-classes.
I'm new in using patterns and .NET-Programming (OO-Programming) and I'm not
sure, if that work proper. In a little test application I allways get an
compile error, because it is not possible to convert a class2 (subclass of
class1) in a class1 (general singleton class) object by calling
getInstance().

It is possible to inheritance of a singleton class ?
What did I wrong ?

Thanks
Regards
Marcel Hug

[Jon Skeet [C# MVP]]

Marcel Hug wrote:

<snip>

It is possible to inheritance of a singleton class ?

Not generally, no. Singletons rely on the fact that only the singleton
class itself can create an instance. As soon as you can have *one*
derived class creating an instance of itself, you can have *multiple*
derived classes, thus breaking the singleton nature.

You can do various things to ensure at runtime that only one instance
is created (like throwing an exception if a second instance is ever
created), but that's not the same as the normal singleton pattern.

Jon

[Stoitcho Goutsev \(100\) [C# MVP]]

Jon,

With the risk of getting involved into an endless discussion with you I'd
like to say that I believe singleton design pattern doesn't disallow
inheritance. Singleton guarantees single instance of a type and since
derived class *is* its base type then inheritance is allowed as long as
there is only one instance of the base (singleton) type. In other words only
one instance of the singleton class or any of its derived classes can exist.

How one can implement that? Well this is implementation detail. Probably
some combination between singleton and factory design patterns.


--

Stoitcho Goutsev (100) [C# MVP]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

Marcel Hug wrote:

<snip>

It is possible to inheritance of a singleton class ?

Not generally, no. Singletons rely on the fact that only the singleton
class itself can create an instance. As soon as you can have *one*
derived class creating an instance of itself, you can have *multiple*
derived classes, thus breaking the singleton nature.

You can do various things to ensure at runtime that only one instance
is created (like throwing an exception if a second instance is ever
created), but that's not the same as the normal singleton pattern.

Jon

[Jon Skeet [C# MVP]]

Stoitcho Goutsev (100) [C# MVP] <10*@100.com> wrote:

With the risk of getting involved into an endless discussion with you I'd
like to say that I believe singleton design pattern doesn't disallow
inheritance. Singleton guarantees single instance of a type and since
derived class *is* its base type then inheritance is allowed as long as
there is only one instance of the base (singleton) type. In other words only
one instance of the singleton class or any of its derived classes can exist.

How one can implement that? Well this is implementation detail. Probably
some combination between singleton and factory design patterns.

You can implement that so that at runtime an exception is thrown or
whatever, but I see that as fundamentally different from being able to
see clearly that the *only* thing which can construct an instance is
the class itself (due to a private constructor being the only one
available), and that class *only* creating an instance when none has
been created before.

With the classic singleton pattern, there's nothing I can do to even
*try* to create another instance (reflection aside) unless I change the
singleton's code.

If you allow inheritance, then you can break the pattern by adding
another derived class - suddenly the singleton class itself isn't in
control over what calls its constructor, so it has to add extra run-
time checks.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jeff Louie]

Marcel... A singleton pattern can return an instance that implements an
interface. If all concrete types can be abstracted to a generic
interface, then you
can return a "subtype" at runtime.

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***

[GoogleNewsReaderMan]

There's nothing fundamentally wrong with subclassing a class that is
intended to be a singleton.
There are many reasons you might want to do it.
And there are many ways to accomplish it.

[chris martin]

> There's nothing fundamentally wrong with subclassing a class that is

intended to be a singleton.
There are many reasons you might want to do it.
And there are many ways to accomplish it.

Not if I'm a good boy and declare my singleton as "public sealed class Singleton".
;)

[Bruce Wood]

> For the database A I created a singleton class AProxy and for the database B

the same as BProxy. Initializing and connetcing to the Database is the same
in both classes (except of the database-path, which is a parameter), just
the Functions are different, because the tables are different.
Now I thought about creating a general DBConnectifity-class (or interface)
to generalize the Initializing and db-connection stuff in this class and
define the specific function in the sub-classes.

Before this discussion spirals out of control :-), notice that the OP
isn't asking that the DBConnectivity class be a singleton, only that
its derived classes be singletons. There is nothing in the singleton
pattern that says that the singleton can't inherit from a base class,
or that the various derived classes from a base class can't be
singletons.

That said, the only thing you _can't_ do within the letter of the law
is put the singleton code in the base class, and have inheriting
classes inherit their "singleton-ness" from the base. Neither can you
guarantee that each derived class is a singleton. You have to write the
singleton pattern code in each derived class.

[Jon Skeet [C# MVP]]

GoogleNewsReaderMan <lo***********@hotmail.com> wrote:

There's nothing fundamentally wrong with subclassing a class that is
intended to be a singleton.
There are many reasons you might want to do it.
And there are many ways to accomplish it.

And that's fine, so long as you then accept that the class is no longer
a singleton.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Bruce Wood <br*******@canada.com> wrote:

For the database A I created a singleton class AProxy and for the database B
the same as BProxy. Initializing and connetcing to the Database is the same
in both classes (except of the database-path, which is a parameter), just
the Functions are different, because the tables are different.
Now I thought about creating a general DBConnectifity-class (or interface)
to generalize the Initializing and db-connection stuff in this class and
define the specific function in the sub-classes.
Before this discussion spirals out of control :-), notice that the OP
isn't asking that the DBConnectivity class be a singleton, only that
its derived classes be singletons. There is nothing in the singleton
pattern that says that the singleton can't inherit from a base class,
or that the various derived classes from a base class can't be
singletons.

Nope, that's fine.
That said, the only thing you _can't_ do within the letter of the law
is put the singleton code in the base class, and have inheriting
classes inherit their "singleton-ness" from the base. Neither can you
guarantee that each derived class is a singleton. You have to write the
singleton pattern code in each derived class.

Exactly. However, that's what I thouhght was wanted, given this part of
the first post:

<quote>
In a little test application I allways get an
compile error, because it is not possible to convert a class2 (subclass
of class1) in a class1 (general singleton class) object by calling
getInstance().
</quote>

Note that class1 here is meant to be a singleton class, and class2 is
derived from it - hence breaking its singleton nature.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too