I heard that a private constructor prevents object creation from the outside world.
When I have a code
public class Product
{
public string Name { get;set;}
public double Price {get;set;}
Product()
{
}
public Product(string _name,double _price)
{
}
}
Here I still can declare a public constructor (parameter), won't it spoil the purpose of the private constructor? When do we need both private and public constructor (parameter) in code?
I need a detailed explanation please.
The reason you would use the pattern you're describing is when you want to control how the object is instantiated.
In your example, for instance, you're saying the only way to create a Product is by specifying its name and price. This is with respect to the outside world, of course. You could also do something similar using other access modifiers, and it would have different implications, but it all boils down to controlling how you want the objects instantiated with respect to who will be doing it.
If you wanted to prevent object creation altogether you would have to make all your constructors private (or protected). That would force the object to be created from within itself (or an inherited class).
Also, as Matti pointed out in the comment below, when you define a constructor that is parameterized you don't need to specify a private default constructor. At that point it is implied.
Constructors can be chained together to avoid having to duplicate code. It is quite common to have private constructors, that nobody is supposed to call outside of the class, that are chained from a public constructor.
Example:
public class Test
{
private Test(int? a,string b) { }
public Test(int a) : this(a, null) { }
public Test(string b) : this(null, b) { }
}
Here there are two public constructors, one taking a string and one taking an int. They both chain to the common private constructor that takes both arguments.
Also, you can construct new objects from within the same class by using the private constructor. For instance, when you want specialized constructors only available through static factory methods:
public static Test Create()
{
int? a = ReadConfigurationForA();
string b = ReadConfigurationForB();
return new Test(a, b);
}
When it is not be a good idea to expose a private constructor to the outside world, add a static factory method that fetches the correct arguments to pass on the constructor.
You need a private constructor when you only want that constructor to be called from within the class itself. In your example you are forcing the calling object to provide 2 parameters when creating the object.
With a private constructor you could do something like:
public static GetInstance ()
{
return new YourObject();
}
but nothing else except the object could call the parameterless constructor.
It's commonly used to create a singleton pattern:
http://www.dofactory.com/Patterns/PatternSingleton.aspx
You would use a constructor with parameters when you wanted to force calling code to pass a value to the constructor in order to create an instance of your class. In your example, calling code must use the parameter version of the constructor in order to create a Product.
A private constructor is a special instance constructor. It is commonly used in classes that contain static members only. If a class has one or more private constructors and no public constructors, then other classes (except nested classes) are not allowed to create instances of this class.
For more details refer to this:
http://msdn.microsoft.com/en-us/library/kcfb85a6(VS.80).aspx
Related
I came across a source code with a nested class like this:
public class OuterClass
{
// code of the outer class
protected class NestedClass
{
private string myVar;
private NestedClass() {} // <--- empty private ctor
public NestedClass(string myVar)
{
this.myVar = myVar;
}
}
}
What could be the reason to create this empty private constructor?
I know when implementing a singleton the constructor must be private to prevent other classes to create an instance. However in the case the is another public constructor, so this cannot be the reason.
One reason I thought of would be to not allow the creation of an instance without a value for the variable, that is passed as parameter to the public constructor, but as far as I know this shouldn't be possible when the is simple no other constructor than the public constructor with parameter. Is that correct?
Edit: A answer that was deleted now, mentioned the default constructor. As far as I know a "hidden" default constructor only exists if there is no manually written constructor at all. This is described here:
These constructors are injected into all class declarations that do not introduce other constructors.
Therefore the empty constructor of my nested class, is not a default constructor, but simply a constructor without parameters. I assume that this is the case for top-level classes and nested classes alike.
If you have a non-default constructor and do not specify a default constructor, it will not be possible for any code to access the default constructor, because the compiler will not create one.
If you have a non-default constructor and also specify a private default constructor then it is possible for a NestedClass method to use the default constructor. Your code does not do this, so it is not necessary to provide a default constructor (private or otherwise).
There also an obscure case where it can make a difference: By providing the default NestedClass constructor, you enable reflection to access it.
The following program demonstrates.
If you run it, it will print "Demo.OuterClass+NestedClass".
If you comment-out the private default NestedClass constructor and run it, it will crash.
Other than this unlikely case, I can see no sensible reason to provide the private constructor.
using System;
using System.Reflection;
namespace Demo
{
public class OuterClass
{
protected class NestedClass
{
private string myVar;
private NestedClass(){} // Commenting-out this line will cause the reflection to break.
public NestedClass(string myVar)
{
this.myVar = myVar;
}
}
}
public class MyDerivedClass: OuterClass
{
public MyDerivedClass()
{
Type type = typeof(NestedClass);
var ctor = type.GetConstructor(BindingFlags.Instance|BindingFlags.NonPublic, null, Type.EmptyTypes, null);
var nested = (NestedClass) ctor.Invoke(null);
Console.WriteLine(nested);
}
}
public static class Program
{
private static void Main()
{
var test = new MyDerivedClass();
}
}
}
If you don't want to explicitly allow reflection to call the private default constructor, then I would say that there is indeed no point in providing it, and you should remove it from the code.
I think this means that only this class can create instances of itself using this constructor. Does the code in the class call this constructor anywhere?
Normally you'd have a private constructor if the class wanted to restrict you to calling some sort of factory method defined on it in order to create it, but as there's another constructor defined then this doesn't seem to be the case.
You can use reflection to locate the private constructor, and once you've got the ConstructorInfo for the private constructor you can invoke it in order to create an instance of the class, but this would be a very niche thing to do!
I have a class defined as:
public class DatabaseEntity<T> where T : DatabaseEntity<T> {
public static string Query { get; protected set; }
public static IList<T> Load() {
return Database.Get(Query);
}
}
public class Node : DatabaseEntity<Node> {
static Node() {
Node.Query = #"SELECT Id FROM Node";
}
}
When I run Node.Load() from a codebehind (Window.xaml.cs) the Node's static constructor never fires; or at least doesn't hit a breakpoint and does not set Node.Query to anything other than null.
Is there any reason why this might occur?
Solution
Check out the answers below for a few solutions. For my case, I decided to simply make the Query variable public, and set all instances of Query in one place. (Not ideal, but it works.)
The problem lies in your assumptions about when a static constructor is called. The documentation, which isn't the clearest, states that
It is called automatically before the first instance is created or any static members are referenced.
You may assume that if you call
Node.Load();
that you are calling a static method on the Node class, but in fact you're calling it on the base class, as that is where it is implemented.
So, to fix this, you have two choices. First, you can trigger the static constructor explicitly by creating a new instance of the Node class prior to calling Load()
var foo = new Node(); // static ctor triggered
Node.Load();
or create a protected virtual member that the base class can call in order to get the query value (can't use abstract here, unfortunately)
public class DatabaseEntity<T> where T : Derp {
protected abstract string Query { get; }
public static IList<T> Load() {
return Database.Get(new DatabaseEntity<T>().Query);
}
}
Both of which are hacky. Better to dispense with the statics altogether and go with instance methods. Statics should be used sparingly, as they result in tight coupling and other design headaches such as this.
Yes, static constructors will not be called till the members of the class is first accessed or first instance is created.
In your case you're accessing DatabaseEntity<T>.Load, so static constructor of DatabaseEntity<T> will be called not its derived class ones.
Even though you call Node.Load it is mapped to DatabaseEntity<Node> at compile time. So technically you're not accessing Node class at all.
You can also call class constructors directly using System.Runtime.CompilerServices and the RuntimeHelpers type by doing something as follows:
RuntimeHelpers.RunClassConstructor(type.TypeHandle);
So for example you could use reflection to loop over all types in an inheritance chain and call each of the static constructors.
How are static constructors and private constructors different?
public class WorkstationDevicePresenter
{
private WorkstationDevicePresenter()
{}
}
What's the point in leaving them blank?
Whats the point in leaving them blank?
There are a number of reasons to make "blank" constructors.
You might make a blank constructor because you want a place to set a breakpoint during debugging.
You might make a blank static constructor because doing so changes the semantics of static field initializers. Read Jon's article on the subject for details.
Let's leave static constructors and consider blank instance constructors.
The key rule that motivates blank constructors is: By default if there are no constructors in a type then you get a "blank" parameterless public constructor for free. If there are any constructors in a type then you do not get a blank parameterless public constructor for free.
So the first obvious reason why you'd want a blank constructor is: I want a blank parameterless constructor, but I've already made another ctor, so I no longer get one for free.
The second reason is that you don't have any ctors and you do not want a blank parameterless public constructor. You might want a blank parameterless private, internal or protected constructor. If that's what you want then you'll have to make one yourself.
In particular, making an empty private ctor as the only ctor means that the class cannot be instantiated via a constructor from outside the class. This is very useful if you want to use the factory pattern. It also prevents code outside the class from making derived classes, because derived classes must be able to call a constructor. If all the constructors are private then they can't derive.
I frequently use this variation on the factory pattern:
public abstract class Thing
{
private Thing() {}
private class RedThing : Thing { ... }
public static Thing GetRedThing() { return new RedThing(); }
}
See, by making a private constructor I can make a public abstract class that can only be instantiated by my code and only extended by my code, and therefore I have a nice invariant: every time I see an object of type Thing, I know where it came from.
Static constructors happen once when the class is loaded, private constructors happen when they are called by some public static method typically used to create singletons, or with the Builder pattern. There is no reason to have a blank private constructor (that I know of).
Static constructors initialize the static parts of a class and private constructors can only be used by the class itself, like for creating a singleton-object of the class.
public class MyClass {
private static int staticitem;
private int instanceitem;
static MyClass(){
staticitem = 0; //define value for staticitem
}
private MyClass() { //can only be called from within the class
instanceitem = 0; //define value for instanceitem
}
public static MyClass GetMyClass() {
MyClass m = new MyClass();
return m;
}
}
Blank private constructor will make the class uninstantiable by anything other than itself. If you don't have this piece of code, by default the compiler creates a blank public parameterless contstructor.
Static constructor is called when creating the static instance.
You can use both to create a Singleton pattern, for instance.
Check the following code:
public class Singleton
{
public static Singleton Instance;
static Singleton
{
Instance = new Singleton();
}
private Singleton()
{
}
}
public class SomeOtherClass
{
public static Singleton CompileError = new Singleton();
public static Singleton CompileOK = Singleton.Instance;
}
Although a static class has only one instance and can't be instantiated, a class with a private constructor can't be instantiated (as the constructor can't be seen), so every time you call this class, this is the same one instance?
Factory classes always follow the last convention (instance class with private constructor). Why is this?
Thanks
There's nothing stopping the class with the private constructor from having a public static method which returns instances of the class:
public class NoPublicConstructor
{
private NoPublicConstructor()
{
}
public static NoPublicConstructor NewInstance()
{
return new NoPublicConstructor();
}
}
As you can see, the static method does not return the same one instance.
edit: One of the reasons factory classes do this is to be able to separate responsibility in future versions: while your code always calls the factory creation method, the author may move all the "guts" out of that class into a different one and your code won't need to know the difference. Calling that class' (public) constructor ties it to an extent to the original class implementation.
You can't* get an instance from outside the class, but you can from inside. A static method or an inner class can create and return an instance of the class with a private constructor. The static class cannot be instanced by anything.
class Foo
{
private Foo()
{
}
public class Bar
{
public Bar()
{
}
public Foo GetFoo()
{
return new Foo();
}
}
}
..
Foo.Bar fooBar = new Foo.Bar();
Foo foo = fooBar.GetFoo();
Edit: *I use the term "can't" loosely. Brian Rasmussen pointed out in the comments to the OP that another method to obtain an instance is through a call through System.Runtime.Serialization.FormatterServices, and this is external to the class itself.
Foo foo = (Foo)System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(typeof(Foo));
Creating a class with private constructor is the common pattern for implementing a "Singleton" object.
The Singleton usually will instantiate an instance of itself, and only allow access to it through a static "Instance" property, which means there's only ever one instance of the class.
The advantage of using a Singleton over a purely static class is that you can utilize interfaces and different implementation classes within the singleton. Your "Singleton" might expose an interface for a set of methods, and you can choose which exact implementation class to instantiate under the covers. If you were using a purely static class, it would be hard to swap out a completely different implementation, without impacting other code.
The main downside of Singleton is that it's difficult to swap out the implementation class for testing, because it's controlled within the Singleton private methods, but there are ways to get around that.
I have a class that I am trying to do unit tests on. The class is a WCF Service Class. (Making it a generics class is not my goal.)
I have a data access layer (DAL) type (called UserDAL) that is instantiated in many methods. To get these methods under test, I need to get this local variables mocked. (Each instance of UserDAL has method specific value in it, so changing it a class level variable would result in messy code, so I would rather not do that.)
What I am thinking would be nice is to overload the constructor and pass in a type to use in the local methods. The empty param constructor would still create a normal UserDAL, but the overloaded one would have a mock type that implements IUserDAL.
I am not sure of the syntax to say I want to pass in a type. Note that I am not trying to pass in a variable, but a type.
Example:
public class MyWCFClass: IMyWCFClass
{
private TypeParam _myUserDALType;
public MyWCFClass()
{
_myUserDALType = UserDAL;
}
public MyWCFClass(TypeParam myUserDALType)
{
_myUserDALType = myUserDALType;
}
//methods to use it
public MyMethod()
{
IUserDAL userDAL = new _myUserDALType();
//Call method in IUserDAL
userDAL.CreateUser();
}
// Several similar methods that all need a different UserDAL go here
.....
}
So, I don't know what kind of type TypeParam is (I made that up) or if this kind of think is even possible.
If you have a non generics solution that would be great.
What you are really looking for is Dependency Injection, but you can do this by passing in a Type argument and then using Activator.CreateInstance(Type) to create the object when you need it.
As far as doing real DI (which will make doing this testing a lot easier), I know that Spring.Net works reasonable well.
You mean Type, using Activator.CreateInstance to create instances:
public class MyWCFClass: IMyWCFClass
{
private Type _myUserDALType;
public MyWCFClass()
{
_myUserDALType = typeof(UserDAL);
}
public MyWCFClass(Type myUserDALType)
{
_myUserDALType = myUserDALType;
}
//methods to use it
public void MyMethod()
{
IUserDAL userDAL = (IUserDAL) Activator.CreateInstance(_myUserDALType );
//Call method in IUserDAL
userDAL.CreateUser();
}
}
Use a Type, and use Activator.CreateInstance to instantiate it:
private Type _myUserDALType;
IUserDAL userDAL = Activator.CreateInstance(_myUserDALType) as IUserDAL;
Your real problem is not in the generics or lack thereof. Your real problem is that MyWFCClass is calling both new and the method. As per Misko Hevery, you get the best testability by separating classes that call new from classes that implement logic. Instead of having MyWFCClass somehow know the type that you want to implement and using reflection, just pass the IUserDal object to the constructor, allowing the test harness to pass in a mock object when needed.
If, for some reason, you can't do this and you can't use generics, then you have to do it yourself. Pass a Type object to the MyWFCClass constructor, then use reflection to find and invoke the constructor you want.
If you want to pass in a type, you can use the Type object:
public class A
{
public A(Type classType)
{
object myObject = Activator.CreateInstance(...classType...);
}
}
public class B
{
...
}
public class C
{
public static void main(string[] args)
{
A a = new A(typeof(B));
}
}
Far simpler, and more consistent with other applications that have this problem, would be to extract an interface on UserDal, then you would have something more like:
public MyWCFClass() : this(new UserDAL())
{
}
public MyWCFClass(IUserDal userDAL)
{
_myUserDAL = myUserDAL;
}
This is also easier to use with dependency-injection frameworks than your proposed method, though that's certainly a secondary concern
(Edited to clarify an alternative solution based on other comments)
If your DAL is essentially worthless after use because it is mutated, take a constructor with IUserDalFactory instead, with one method Create().
If IUserDAL defines the interface that your WCF service needs to get its job done, why not just take an instance of it as a constructor parameter? And since WCF requires a default constructor, why not have that default constructor call your parameterized constructor with a default implementation?
public class MyWCFClass : IMyWCFClass
{
private readonly IUserDAL _userDAL;
public MyWCFClass()
: this(new DefaultUserDAL())
{
}
public MyWCFClass(IUserDAL userDAL)
{
_userDAL = userDAL;
}
}
If you're using a dependency injection container, you could expose it as a singleton and satisfy the parameterized constructor by using that singleton:
public MyWCFClass()
this(Container.Instance.Resolve<IUserDAL>())
{
}
With this approach, your WCF class has everything it needs to get its job done, but it is still unit-testable. Moreover, it is not responsible for creating its dependencies, which is a good thing.
In C# there is a type called "Type". With it you can create a parameter and pass in any valid type.
private void MyMethod(Type myType)
{
//Do something
}