Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Private Constructors

Status
Not open for further replies.

vbkris

Programmer
Jan 20, 2003
5,994
IN
Hi guys,

When should we implement a private constructor?

MSDN states that we should use one when a class is declared as static.

However the SqlDataReader class seems to have a "Private" constructor. And to top it the SqlCommand object is able to instantiate it! (ExecuteReader is returning an instance of the SqlDataReader object)

My queries:
a. How is this done technically?
b. What kind of a design pattern is this?


Known is handfull, Unknown is worldfull
 
perhaps sqldatareader has a friend constructor and that would show up as private to you.

Private constructors would be mainly used for singleton patterns and for classes that are module-like (only static/shared methods/attributes)

perhaps sqldatareader is a singleton and perhaps sqlcommand uses that.


Christiaan Baes
Belgium

"My new site" - Me
 
>>perhaps sqldatareader is a singleton and perhaps sqlcommand uses that.

how?
SqlCommand is just a normal class like any other. How is it able to instantiate this?

a singleton class CAN be instantiated right? its just that the same instance is returned.

therefore:
dim myObj as new SingleTonClass

is OK no?

one more thig, can you clarrify this "Friend" concpet. How is it different from Protected and how is this concept implemented in C#???

Known is handfull, Unknown is worldfull
 
The idea of the singleton is that you don't have a public constructor, specifically to prevent people from instantiating more than one of them. You call a non-constructor method to return the singleton instance. If it doesn't exist, the method calls the private constructor to create it. Then it returns a reference to the singleton instance.

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object::perlDesignPatterns)[/small]
 
hi steve,

Could i have a sample code for this?

>>If it doesn't exist, the method calls the private constructor to create it.

which methopd do you mean? SqlCommand class.

One more thing, i dont think its a Singleton class because multiple users can access the same class (SqlDataReader) across multiple pages. This might lead to confusion...

Known is handfull, Unknown is worldfull
 
Google 'C# singleton example" for about ten possibilities, including MSDN.

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object::perlDesignPatterns)[/small]
 
OK,

I will try to build a class similar to the one as SqlDataReader using a singleton class and get back to you.

But is this assumption right?
One more thing, i dont think its a Singleton class because multiple users can access the same class (SqlDataReader) across multiple pages. This might lead to confusion...


Known is handfull, Unknown is worldfull
 
An example from MSDN, taking maximum advantage of all the facilities in .NET to reduce it to the bare minimum
Code:
// .NET Singleton
sealed class Singleton 
{
    private Singleton() {}
    public static readonly Singleton Instance = new Singleton();
}
Obviously you'd need to add some properties and methods to get something useful, but you get the idea. Watch out for thread safety issues.

The singleton pattern (GoF) is very useful in the right place. For some reason, people think it's cool and have a habit of over-using it where they don't really need it.

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object::perlDesignPatterns)[/small]
 
You will never have
Code:
dim MyObject as new MySingletonClass

You may have
Code:
dim MyObject as MySingletonClass = MySingletonClass.GetCurrentInstantiation

If you have a .GetCurrentInstantiation method that returns the shared object of type MySingletonClass. Such as

Code:
public class MySingletonClass

private shared CurrentInstantiation as MySingletonClass

private sub new 
  'set values and what not
end sub

public shared function GetCurrentInstantiation as MySingletonClass
  if CurrentInstatiation is nothing then CurrentInstantiation = new CurrentInstantiation

  return CurrentInstantiation 
end function

-Rick

VB.Net Forum forum796 forum855 ASP.NET Forum
[monkey]I believe in killer coding ninja monkeys.[monkey]
 
Use private constructors in a factory class:
Code:
// C++ example
class CFactory
{
public:
   static CFactory Create();  // Creates a new CFactory.

private:
   CFactory();
   CFactory( const CFactory& );
   CFactory& operator=( const CFactory& );
}
Now the only way to make a CFactory object is by calling CFactory::Create().

Another use of private constructors is to prevent the compiler from automatically creating default constructors.
Code:
// C++ again, sorry.
class CSomething
{
public:
   CSomething( int var1, double var2 );  // This is the only constructor you're allowed to use.

private:
   CSomething();
   CSomething( const CSomething& );
   CSomething& operator=( const CSomething& );
}
If you only want people to use a certain constructor other than the default constructor, copy constructor or assignment operator, then make those private so the compiler doesn't create empty versions...
 
vbkris, the point about a Singleton class is that it isn't default behavior. So, the way to create one is to either cause the constructor to return an existing instance if there and create one if not there, or disable direct instantiation altogether and require clients to call a method. Personally, I lean towards the latter, since it is clearer that a Singleton pattern is in use.

Stevexff, very elegant, and I agree with you about the overuse of the Singleton pattern. I believe it's because it's the easiest pattern to understand, and so people who have a beginning understanding of them go around name dropping ("Hey, I'm familiar with GoF patterns, why just last week I was implementing a Singleton architecture...."). Human nature, yaknow?

:)

Bob
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top