I was working in the Microsoft.Ink dll recently using C# and was debugging a problem (which is not related to this) I noticed, that when I was debugging it, ink objects had a strokes object, which had an ink object, which had.... etc.
This confused me, as I was under the assumption you could not do this (I come from a C++ Background)
But I ignored it, solved the problem, and moved on. Today, I run into a similar problem, as I look at a class which had a private member which was the same class as itself.
public sealed class Factory
{
private static Factory instance = new Factory();
}
How is that even possible? I can now call instance.instance.instance.instance...etc. This, as you can imagine, hurts my mortal brain, and I'm sure it can't be good on the computer either. How does the compiler deal with this? And Just how deep does the rabbit hole go?
Because it's static and therefore there is only one copy of the variable instance within the AppDomain.
What you're thinking of is this:
public class Foo
{
private Foo lol = new Foo();
}
Notice, everything here is instance, not static.
As the commenters noted (long ago), this is valid syntactically, but would result in a StackOverflowException being thrown, as the assignment requires construction, and construction creates a new assignment. One triggers the other in a cycle that ends when the call stack reaches its maximum length.
In OP's example, assignment requires construction, but the assignment is triggered by the static constructor, not the instance constructor. The static constructor only executes once within an AppDomain, in order to initialize the class' Type. It isn't triggered by instance construction, and so (in OP's example) won't result in a stack overflow.
it's not necessarily recursive by nature. think of a linked list. or a tree.
class Directory
{
string name;
Directory parentDirectory;
}
It's just allows objects of that class to have an internal reference to another object of that class.
This is a software pattern known as "Singleton".
Some people frown upon the use of the pattern for more reasons than just stated in the question but for better or for worse it is a common pattern in the .NET Framework. You will find Singleton Properties (or fields) on classes that are meant to be instantiated only once. Think of a static Instance property as a global hook upon which to hang an object.
Since this is a class, and not a struct, when you declare a field that is the class, you are only defining a reference to a class. This allows you to keep having references, provided you assign them.
In your case, you're reference allocates a new class, but it is static, so it's only going to do it one time, no matter how many classes you create. The instance constructor runs the first time Factory is used, and will call a single non-static constructor. Doing instance.instance.instance is not allowed, since instance is static. You cannot access a static variable from a member - you need to do Factory.instance.
However, you ~could~ make instance non-static, and have it be a reference to some other "Factory" class, or even a reference to this. In that case, you could chain instance.instance.instance - but it will just follow the references as long as you've set them. Everything works, no problems.
There will only ever be one instance of 'instance' because it is static. The only way you should be able to access it is by calling Factory.instance.
string text = Factory.instance.ToString(); // legal
string text2 = Factory.instance.instance.ToString(); // compiler error
I think you should ask the other way around: Why shouldn't this be possible? Factory is just a type like any type which gets resolved by the compiler.
As most of the answers here point out that this is working only because Factory is a static field, I have added the following sample. Please note that this is a very primitive sample of a chained list (you probably wouldn't implement it that way for various reasons, but I didn't come up with a better example yet). In this example, ChainedListItem is a container for an element of a single-linked list, which contains a field of the very same type to point to the next item in the list. The list has an (empty) head element and the last element is marked by having an empty _nextItem field:
public class ChainedListItem<T>
{
private ChainedListItem<T> _nextItem;
T _content;
public ChainedListItem<T> NextItem
{
get { return _nextItem; }
set { _nextItem = value; }
}
public T Content
{
get { return _content; }
set { _content = value; }
}
public ChainedListItem<T> Add(T content)
{
_nextItem = new ChainedListItem<T>();
_nextItem.Content = content;
return _nextItem;
}
public void Dump()
{
ChainedListItem<T> current = this;
while ((current = current.NextItem) != null)
{
Console.WriteLine(current._content);
}
}
}
class Program
{
static void Main(string[] args)
{
ChainedListItem<int> chainedList = new ChainedListItem<int>();
chainedList.Add(1).Add(2).Add(3);
chainedList.Dump();
}
}
The "rabbit hole" goes as deep as your stack space allows you to make another call to the constructor of the type. If you try to go deeper than that, you will get a stackoverflow exception as with any other recursion.
By the way, the code that you wrote in your answer is showing a very basic implementation of a Singleton which is actually based on having a (private) static member of the same type as the surrounding type.
And, last but not least, such constructs are also perfectly fine in C++.
It is a singleton. Meaning there is really only one instance of the class.
Is that the entire class? Typically in C# you will see a singleton like
public class SomeClass
{
static readonly SomeClass instance = new SomeClass();
public static SomeClass Instance
{
get { return instance; }
}
static SomeClass()
{
}
SomeClass()
{
}
}
I'm not sure how you would even access the instance since it is private. The only thing this would be useful for is a Singleton implementation, but if that is the case you are mission the public property exposing the instance.
This is done all the time is most OO languages. instance is a static member of Factory. There is nothing unusual about this code. It is standard Factory pattern. Do you also have a problem with code like this?
x = x + 1;
Related
I want to maintain a list of all instances of my class that are created. I thought I could do that by adding 'this' to a static list from within the constructor. Of course C# doesn't let me reference 'this' in the constructor because it's not fully constructed yet. That makes sense but I'm trying to figure out the best way to accomplish this.
class Thing
{ static List<Thing> AllTheThings;
public Thing()
{
AllTheThings.Add(this); // can't reference 'this' here
}
}
I can think of two ways to this:
Make the constructors private and create a static method ('MakeNewThing') that invokes the constructor and adds the new instance to the list. I worry about potential problems with not having a public constructor but I'm not sure what they are.
Create a shell class ('ThingShell') that contains Thing's. The constructor for ThingShell creates a Thing and adds it to the list. This is messy and requires ThingShell to proxy all of Thing's members.
I seem to remember doing something like this in C++ about 20 years ago but don't recall the details and can't find the code.
Anyone have a better ideas?
As #Jon Skeet said, that reference to "this" should have been fine. But just in case, here is an alternate method.
public class Thing
{
public readonly static List<Thing> AllTheThings = new List<Thing>();
//making the constructor private so that no other code can call it.
private Thing() { }
//providing a static instance method for creating the object
public static Thing Instance()
{
var t = new Thing();
Thing.AllTheThings.Add(t);
return t;
}
}
Now, the thing (excuse the pun) to watch out for in this implementation is that, by having this static list of all "Things" instantiated by the app, you will run the risk of a memory sinkhole if you do not have a way to get rid of old "Things" when they are no longer needed within scope.
What makes it possible to create a instance of class inside of the class itself?
public class My_Class
{
My_Class new_class= new My_Class();
}
I know it is possible and have done it myself but I cannot still make myself believe that this is not something like " who was first--Chicken or egg ?" type of problem. I could be glad to receive an answer that will clarify this from programming perspective as well as from JVM/ compiler perspective. I think understanding this will help me clear some very important bottleneck concepts of OO programming.
I have received some answers but none are clear to the degree I expected.
There is absolutely no problem in creating instances of a class in the class itself. The apparent chicken-or-egg problem is solved in different ways while the program is being compiled and when it is being run.
Compile-time
When a class that creates an instance of itself is being compiled, the compiler finds that the class has a circular dependency on itself. This dependency is easy to solve: the compiler knows that the class is already being compiled so it won't try to compile it again. Instead, it pretends that the class already exists generates code accordingly.
Run-time
The biggest chicken-or-egg problem with a class creating an object of itself is when the class does not even exist yet; that is, when the class is being loaded. This problem is resolved by breaking class loading into two steps: first the class is defined and then it is initialized.
Defining means registering the class with the runtime system (JVM or CLR), so that it knows the structure that objects of the class have, and what code should be run when its constructors and methods are called.
Once the class has been defined it is initialized. This is done by initializing static members and running static initializer blocks and other things defined in the particular language. Recall that the class is already defined at this point, so the runtime knows what objects of the class look like and what code should be run to create them. This means there's no problem whatsoever to create objects of the class when initializing it.
Here's an example that illustrates how class initialization and instantiation interact in Java:
class Test {
static Test instance = new Test();
static int x = 1;
public Test() {
System.out.printf("x=%d\n", x);
}
public static void main(String[] args) {
Test t = new Test();
}
}
Let's step through how the JVM would run this program. First the JVM loads the Test class. This means that the class is first defined, so that the JVM knows that
a class called Test exists and that it has a main method and a constructor, and that
the Test class has two static variables, one called x and another called instance, and
what is the object layout of the Test class. In other words: what an object looks like; what attributes it has. In this case Test doesn't have any instance attributes.
Now that the class is defined, it is initialized. First of all, the default value 0 or null is assigned to every static attribute. This sets x to 0. Then the JVM executes the static field initializers in the source code order. There are two:
Create an instance of the Test class and assign it to instance. There are two steps to instance creation:
First memory is allocated for the object. The JVM can do this because it already knows the object layout from the class definition phase.
The Test() constructor is called to initialize the object. The JVM can do this because it already has the code for the constructor from the class definition phase. The constructor prints out the current value of x, which is 0.
Set static variable x to 1.
Only now the class has finished loading. Notice that the JVM created an instance of the class, even though it was not fully loaded yet. You have proof of this fact because the constructor printed out the initial default value 0 for x.
Now that the JVM has loaded this class, it calls the main method to run the program. The main method creates another object of class Test - the second in the execution of the program. Again the constructor prints out the current value of x, which is now 1. The full output of the program is:
x=0
x=1
As you can see there is no chicken-or-egg problem: the separation of class loading into definition and initialization phases avoids the problem completely.
What about when an instance of the object wants to create another instance, like in the code below?
class Test {
Test buggy = new Test();
}
When you create an object of this class, again there is no inherent problem. The JVM knows how the object should be laid out in memory so it can allocate memory for it. It sets all the attributes to their default values, so buggy is set to null. Then the JVM starts initializing the object. In order to do this it must create another object of class Test. Like before, the JVM already knows how to do that: it allocates the memory, sets the attribute to null, and starts initializing the new object... which means it must create a third object of the same class, and then a fourth, a fifth, and so on, until it either runs out of stack space or heap memory.
There is no conceptual problem here mind you: this is just a common case of an infinite recursion in a badly written program. The recursion can be controlled for example using a counter; the constructor of this class uses recursion to make a chain of objects:
class Chain {
Chain link = null;
public Chain(int length) {
if (length > 1) link = new Chain(length-1);
}
}
Other responses have mostly covered the question. If it helps wrap a brain around it, how about an example?
The chicken-and-egg problem is resolved as any recursive problem is: the basis case which doesn't keep producing more work / instances / whatever.
Imagine you've put together a class to automatically handle cross-thread event invocation when necessary. Heavily relevant for threaded WinForms. Then you'd like the class to expose an event which occurs whenever something registers or unregisters with the handler, and naturally it should handle cross-thread invocation as well.
You could write the code that handles it twice, once for the event itself and once for the status event, or write once and re-use.
The majority of the class has been trimmed out as it isn't really relevant to the discussion.
public sealed class AutoInvokingEvent
{
private AutoInvokingEvent _statuschanged;
public event EventHandler StatusChanged
{
add
{
_statuschanged.Register(value);
}
remove
{
_statuschanged.Unregister(value);
}
}
private void OnStatusChanged()
{
if (_statuschanged == null) return;
_statuschanged.OnEvent(this, EventArgs.Empty);
}
private AutoInvokingEvent()
{
//basis case what doesn't allocate the event
}
/// <summary>
/// Creates a new instance of the AutoInvokingEvent.
/// </summary>
/// <param name="statusevent">If true, the AutoInvokingEvent will generate events which can be used to inform components of its status.</param>
public AutoInvokingEvent(bool statusevent)
{
if (statusevent) _statuschanged = new AutoInvokingEvent();
}
public void Register(Delegate value)
{
//mess what registers event
OnStatusChanged();
}
public void Unregister(Delegate value)
{
//mess what unregisters event
OnStatusChanged();
}
public void OnEvent(params object[] args)
{
//mess what calls event handlers
}
}
The main thing I always see myself creating an instance from within the class, is when I am trying to reference a non-static item in a static context, such as when I am making a frame for a game or whatever, I use the main method to actually set up the frame. You can also use it for when there is something in a constructor that you want to set (like in the following, I make my JFrame not equal to null):
public class Main {
private JFrame frame;
public Main() {
frame = new JFrame("Test");
}
public static void main(String[] args) {
Main m = new Main();
m.frame.setResizable(false);
m.frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
m.frame.setLocationRelativeTo(null);
m.frame.setVisible(true);
}
}
Creating a instance of an object inside the object could lead into a StackOverflowError since every time that you create an instance from this "Test" class you will be creating another instance and another instance and so on.. try to avoid this practice!
public class Test {
public Test() {
Test ob = new Test();
}
public static void main(String[] args) {
Test alpha = new Test();
}
}
The attribute to hold self instance should be static
public class MyClass {
private static MyClass instance;
static {
instance = new MyClass();
}
// some methods
}
I have some code as shown below. I guess it is Singleton pattern. Why do I need a static constructor. Also what is the advantages of this? Thanks for your reply ...
public sealed class Myclass
{
static Myclass()
{
Myclass.Application = new Myclass();
}
protected Myclass()
{
}
static Myclass _application;
public static Myclass Application
{
get { return Myclass._application; }
protected set { Myclass._application = value; }
}
string _name;
public string Name
{
get { return _name}
protected set { _name= value; }
}
}
To start with, this class is somewhat odd for having a protected constructor. It's not a fatal flaw given that it's sealed, but it's distinctly odd.
There's a potential difference in timing between this code and the nearly-equivalent use of a static variable initializer:
static readonly Myclass _application = new Myclass();
(There's no need for a setter in this case, of course.)
You can't do that with an automatically implemented property though.
Using static initialization in some form gets you "free" thread-safety - you don't need to do any locking in order to get lazy initialization.
You may find my singleton implementation article interesting for more options.
Usage of a type ctor here is a guarantee that singleton instance will be initialized once. It's more simple that double-checked lock pattern, when implementing lazy singleton initialization, but it has disadvantage the same reason - singleton creation may be very expensive, and singleton may never be used during app lifetime.
There is no immediate advantage in the static constructor as opposed to a lazy-instantiated on get approach, other than thread safety as pointed out by Jon Skeet's answer. This may or may not be relevant in your situation, though you don't specify anything. It just makes the code look different, but is going to result in the same functionality.
The "advantage" of the singleton pattern is that is allows easy access to a single instance of a class, basically a sort of "globally" accessible instance of the class.
I say "advantage" as there are many discussions about the Singleton pattern being an anti-pattern. I am on the fence. In a small application this can function OK and most of the proposed alternative solutions involve Dependency Injection frameworks (often sometimes with the life-span of "Singleton"!), which may be impractical on smaller apps.
Just a note, having a sealed class with protected members is pointless - sealed classes cannot be inherited.
If you write in this way you can use auto property and do not actually implement it.
Say like this:
public sealed class Myclass
{
static Myclass()
{
Myclass.Application = new Myclass();
}
.....
public static Myclass Application {get;set;}
...
}
Basically, there is no any practcal advantage if not like this one: code-style.
You have to create the instance of the class somewhere, and that can either be in a static constructor, or in the property that gets the instance.
Anyhow, it's not a good code example that you have found.
It has protected members even though it's sealed, which only makes the code confusing. They should be private.
If you look at the Name property you will notice that it's impossible to set it, so it will always be null.
static constructor it gets called during the loading of the assembly...
EDIT:
thanks jon I was wrong...
now i understand static constructors in C# are specified to execute only when an instance of the class is created or a static member is referenced..
I have a class which you pass in a folder and then it goes off and processes a lot of data within the specified folder.
For instance:
MyClass myClass = new MyClass(#"C:\temp");
Now it goes off and reads say a couple of thousand files and populates the class with data.
Should I move this data out from the constructor and have it as a separate method, such as the following?
MyClass myClass = new MyClass();
myClass.LoadFromDirectory(#"C:\temp");
Maybe you should try it this way with a static method that returns an instance of the object.
var myClass = MyClass.LoadFromDirectory(#"C:\temp");
This will keep the initialization code outside of your constructor, as well as giving you that "one line" declaration you are looking for.
Going on the comment from below from the poster, by adding State an implementation could be like so:
public class MyClass
{
#region Constructors
public MyClass(string directory)
{
this.Directory = directory;
}
#endregion
#region Properties
public MyClassState State {get;private set;}
private string _directory;
public string Directory
{
get { return _directory;}
private set
{
_directory = value;
if (string.IsNullOrEmpty(value))
this.State = MyClassState.Unknown;
else
this.State = MyClassState.Initialized;
}
}
#endregion
public void LoadFromDirectory()
{
if (this.State != MyClassState.Initialized || this.State != MyClassState.Loaded)
throw new InvalidStateException();
// Do loading
this.State = MyClassState.Loaded;
}
}
public class InvalidStateException : Exception {}
public enum MyClassState
{
Unknown,
Initialized,
Loaded
}
It depends. You should evaluate the basic purpose of the class. What function does it perform?
What I usually prefer is to have a class constructor do the initialization necessary for the functioning of the class. Then I call methods on the class which can safely assume that the necessary initialization has been done.
Typically, the initalization phase should not be too intensive. An alternative way of doing the above may be:
// Instantiate the class and get ready to load data from files.
MyClass myClass = new MyClass(#"C:\temp");
// Parse the file collection and load necessary data.
myClass.PopulateData();
I agree with Ari and others - split them up.
A constructor should really do the minimum amount of work (simply initialise the object ready for use and leave it at that). By using a separate method to do the work:
It is clearer to the caller that the worker function may take a long time.
It is easy to provide several constructors to initialise the object with different information (e.g. you might be able to pass in your own class (rather than a string) that can supply the pathname. Or you could pass in an extra parameter that specifies a wildcarded filename to match, or a flag to specify if the search should recurse into subfolders).
You avoid any issues with the constructor. In the constructor the object is not fully formed, so it can be dangerous to do work - e.g. calling a virtual function inside a constructor is a very bad idea. The less code you put in the constructor the less likely it is that you'll do something "bad" by accident.
It's cleaner coding style to separate different behaviours/functions into separate methods. Keep initialisation and work separated
A split class will be easier to maintain and refactor in future.
Is this all your class does? If so, then I would say it doesn't really matter. But it is likely that you're class is actually doing more than what you have shown. Does it have any error handling, for example?
The purpose of the constructor is to construct an object. The purpose of a method is to perform an action. So my vote is for this form:
MyClass myClass = new MyClass();
myClass.LoadFromDirectory(#"C:\temp");
I think you should decide between the two approaches above ("first initialize, then execute" vs "empty init, perform with params") based on whether you plan on reusing the same object to perform the same operation on a differnt input.
if the class is only used to run the task on a fixed param, I'd go with initializing it in the constructor (making it readonly even), and then performing the task on a different method.
If you want to keep performing the the task on different params, I'd put it in the task method itself.
If all the class does is this task, I'd also consider changing it all to a static class/methods - it doesn't need to keep its internal state.
Anyway, I would never put the task itself in the constructor. As Cerebrus said, the initialization should be fast.
Unless the main purpose of your class is to perform I/O, you should probably not be performing I/O (potentially throwing an IOException) in the constructor.
Consider splitting the class in two:
interface IMyDataSource
{
// ...
}
class FileDataSource: IMyDataSource
{
public FileDataSource(string path)
{
// ...
}
}
class MyClass
{
public MyClass(IMyDataSource source)
{
// ...
}
}
IMyDataSource myDS = new FileDataSource(#"C:\temp");
MyClass myClass = new MyClass(myDS);
That way the main class can focus on managing its own state, while the data source builds the initial state from the file contents.
If that is the only resource the class works with, it'd probably be better to pass the path to the constructor. Otherwise, it would be a parameter to your class members.
My personal preference would be to use C# 3.0 initializers.
class MyClass {
public string directory;
public void Load() {
// Load files from the current directory
}
}
MyClass myClass = new MyClass{ directory = #"C:\temp" };
myClass.Load();
This has a few advantages:
Object instantiation won't have an
automatic file system side effect.
All arguments are named.
All arguments are optional (but,
of course, could throw an
exception in Load() if not defined)
You can initialize as many properties as you
want in the instantiation call
without having to overload the
constructor. For instance, options
for whether to recurse directories,
or a wildcard for filespec to search
for.
You could still have some logic
in the setter for directory to do
some stuff, but again, side effects
are usually not a good thing.
By performing file operations in a
separate procedure call, you avoid
the issue of not being able to
reference your myClass instance in
the exception handler.
I'm going to echo the "split them up" folks here. If it helps, try this:
Ask yourself, "What does this method/property/field do?"
Make it do that; no more, no less.
Applying that here, you get this:
The constructor is supposed to create the object.
Your method is supposed to load its data from the filesystem.
That seems to me to be a lot more logical than "The constructor is supposed to create the object and load its data from the filesystem.
As an exercise, I'm translating parts of our large and battle-hardened Delphi-framework to C#.
Included in this framework is a generic singleton parent class. Of course, implementing a singleton in C# is fairly easy (there is even a Jon Skeet article, so what more could I wish for), but our Delphi singleton has a slightly different take on the pattern: as opposed to publishing an 'instance' property/method, it has a "fake" constructor that always returns the same instance. The essential characteristic of this approach is that the user of the singleton class doesn't know that he is dealing with a singleton:
as far as they know, they just construct any old class and request some information from it.
I want to accomplish the same thing in C# (as an exercise, so it doesn't have to be production-quality code, evil hackery is fine), but so far I've failed.
Any suggestion to make a simple myInstance = new MyClass(); always return the same instance is most welcome!
Additional info
We are talking a convenience-implementation of the singleton pattern, as offered by the framework. It doesn't necessarely have to be a parent-class, but it does have to assist the developers in creating their own singletons as well. Requiring them to manually redirect all their method calls to the single-instance will not make them overflow with joy. :-)
I'm not really interested in debating whether or not this is the right way to deal with singletons, for now I'm just interested in the finer art of c#-tweaking.
You would do a Proxy (Edit: As Tom points out below, the proper design pattern is Monostate):
public class MyClass {
MyActualClass _actual;
public MyClass() {
_actual = MyActualClass. Instance;
}
public DoStuff() {
_actual.DoStuff();
}
}
internal class MyActualClass {
private MyActualClass {
}
public DoStuff() {
...
}
MyActualClass _instance;
public static Instance {
get {
if(_instance == null)
_instance = new MyActualClass()
return _instance;
}
}
}
....
public static void Main() {
var my1 = new MyClass();
var my2 = new MyClass();
}
my1 != my2 but my1.DoStuff() calls the same instance of the method as my2.DoStuff()
This would be simplified even further if you programmed of an interface only.
Edit: The equality problem could partially be solved by making _actual protected internal and overwriting MyClass.Equals(object obj) to check whether this._actual == obj._actual
I believe the Monostate pattern will give you what you need:
"The Monostate gives us the singularity of state that we so treasure in the Singleton, but without all of the static headaches that come along with it."
More here:
http://jeremyjarrell.com/archive/2008/04/21/88.aspx
As far as I know, this cannot be done for real because of how C# handles object instances. In order for a constructor to be called, the instance has to actually be created, and you can't just "return" another object from a constructor.
The best thing I can come up with (other than using a factory method) is to treat the class internally as a Singleton, and create "dummy" instances that all just point back to that original instance, when created. So for example, in your constructor you would check to see if the singleton has been initialized, and if not, would initialize it, then you would basically just proxy each instance's methods and properties back to the singleton.
In this implementation, the singleton needn't even be necessarily the same class, but you could if you wanted to keep things contained.
Update: One drawback of this approach is that although each instance would behave as a singleton, it would still have its own object reference and therefore you might also want to override Equals() for equality comparisons.
I think you could possibly roll something with Remoting.
Update:
A better way would be to wrap a proper singleton class in a struct or lightweight class.
Create the singleton as a static member and make all methods access the single static instance.
class SingletonWrapper {
private static RealSingleton instance = new RealSingleton();
public void methodA() {
instance.methodA();
}
public String getA() {
return instance.getA();
}
}
(This is actually Java code but C# is similar enough, I think. :)
I don't see how you can, as constructors don't use a return statement. You could clone all of the relevant links to the singleton, but it would have local copies of local variables, and be very messy.
Instead have the constructor check if the singleton is instantiated, and if it has been already, throw an exception, or log a warning to the developer who is using the old style code.
How about using a static function to return an object insted of using the new keyword.
static private m_obj my_obj;
static private bool my_new_obj;
static public m_obj create_m_obj()
{
if (my_new_obj == false)
{
my_new_obj = true;
my_obj = new my_obj();
}
return my_obj;
}
Then you have easy full controle over the creation of the object, if I an not mistaken.