We Keep Coding

adding static method to class in c#, I know you can't want alternatives

I'm trying to work Domain Specific Language constructs into my api. What I would really love to do is be able to add a static method to a class via extension, but i have researched that this is not possible from this site. So let's talk about what i really want to do by example.
Say you have some class that serves as a data service (could be a database, or rest or whatever).
The class requires you to initialize it with some, let's say, location data so that it knows where to point. This location information is not going to be known till runtime.
Normally you would do . . .
DataService service = new DataService( locationData );
Order = service.getOrderDetails( orderId );
However, in almost all cases, the user will just need to ask on question of the DataService and then move on, close scope. I would like some idiom that makes this friendlier to the user. When I learned of extension methods by wish was to do this . . .
Order = DataService.at(location).getOrderDetails(orderId);
This, of course, is also possible, but I would like to put this pattern/idiom on to many classes that have this notion of a location. I have tried extension methods (cant be static). I have tried inheriting from a GenericClass that provides an at method:
public class DSL<T>
where T : new()
{
public T at( Location location )
{
return new T(location);
}
}
you can not pass args to a constructor for a variable type :(
I dislike doing the following:
public class DSL<T>
where T : ILocationable, new()
{
public T at( Location location )
{
T result = new T();
result.setLocation( location );
return result;
}
}
because i do not like classes that can be instantiated and not initialized.
What alternatives do you guys have out there, either to add this "at" method or to provide a better idiom for handling this type of api.
UPDATE:
I came up with a mechanism that does what I need:
First I have this in a file in my library/tools area. The file is called DSL.cs
contents below:
namespace R3
{
static public class DSL
{
static public Services.CloudConnection Cloud( string cloud )
{
return Services.CloudFactory.get(cloud);
}
}
}
When I declare a method I want to use this with technique
static public void fixSequenceError(this CloudConnection cloud, OrderId id )
{
if( inSequenceError(cloud, id ) )
{
cloud.db.setOrderStatus(id, BLAH);
cloud.db.setOrderItemsStatus(id, BLAHBLAH);
}
}
then in any file i want to use this idiom in I need to do something funky instead of a standard include:
using static R3.DSL;
Now I can type stuff like:
Cloud( locationData ).fixSequenceError
or
Cloud(orderInfo.cloudLocation).db.changeAppOrderStatus
For efficiency, the CloudFactory is returning a statically allocated object that is associated with that cloudLocation, think many different singletons hashed to identifier. When Cloud( location ).foobar(orderId) is invoked I'm calling foobar using the object specific to that location. I'm doing so without having to prepend every action with Cloud cloud = CloudFactory.getCloud(location)

You could use reflection like this:
public static class DSL
{
public static T at<T>(Location location)
{
return (T)typeof(T).GetConstructor(new[]{typeof(Location)})?.Invoke(new object[] {location});
}
}
This method tries to get a ConstructorInfo and invokes it with the provided Location argument.
When the type T does not have a constructor taking only a Location argument, at will return null.
UPDATE: Decided to make the class static, so you don't need to create an instance when you just want to call it like this:
Order order = DSL.at<DataService>(location).getOrderDetails(orderId);

You could adopt a builder pattern perhaps to avoid classes which are constructed but not valid (although the builder itself might fall into this category):
Order order = new OrderBuilder().using(dataService).at(location).getOrderById(id).Build();
This gives the sort of fluent api you're looking for. I have recently used this for a project.

I would like some idiom that makes this friendlier to the user.
In your case it appears you don't want to use the Object Oriented Programming the way it was designed in c# but would rather use any a Fluent that allows for friendlier code for another programmer (not user).
In this case it seems your only solution would be to use the factory pattern. It's typically used to validate parameters as they are passed in, but in this case can be used to encapsulate the creation of a class to prevent uninitialized classes.
(I'll also mention that lowercased methods are against Microsoft guidelines for naming conventions, so I'll be using Pascal casing in my code.)
DataService.at(location).getOrderDetails(orderId);
Could be coded like:
public class DataService
{
private DataService(Location location)
{
//
}
public static DataService At(Location location)
{
var result = new DataService(location);
return result;
}
public Order GetOrderDetails(int orderId)
{
}
}
Then the code would look exactly like your example:
DataService.At(myLocation).GetOrderDetails(1);
This is only good assuming DataService does not derive from IDisposable.

How does creating a instance of class inside of the class itself works?

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
}

Cross class communication without refering the instances C#

I have two classes that are instantiaded and loaded at runtime. I would like to check the resources of one without having to refer the instances as it can get messy if there are a lot of checks and classes.
For example, if I have the two following classes and I want to call one from another.
Class Item
{
private int id;
private int loc;
void Item()
{
// the Class actually has some properties with get set, but thats not the point here.
id = 1;
loc = 2;
}
public bool check()
{
// Check if the several fields are ok for DB submission
// how Can I refer to the other class from here? Do I have to pass the instance as a parameter?
return Locals.Exists(loc); // does not work because its not static!
}
}
Class Locals
{
Hashtable l = new Hastable();
void Locals()
{
// This will actually be loaded from a DB at runtime.
l.add(1, "Local 1");
l.add(2, "Local 2");
}
public bool Exists(int i)
{
return l.ContainsKey(i);
}
}
//Form Code:
main()
{
Item newItem = new Item();
Locals allLocals = new Locals();
newItem.check();
}
Is there a way to do this without having to call
newItem.check(allLocals);
From what I saw, even with delegates, the caller classe need the instance of the other class.
In short, Is there another way to promote cross Instances communication?
Was I confusing enough?

not sure i understand what you mean, but i usually add for similiar cases a static list with all of the objects
Class Locals
{
public static List<Locals> MyLocals = new List<Locals>(); // first thing i add
Hashtable l = new Hastable();
void Locals()
{
// This will actually be loaded from a DB at runtime.
l.add(1, "Local 1");
l.add(2, "Local 2");
MyLocals.Add(this); // second thing i add
}
and then you can get the objects from a static context.
be sure to edit the dispose function as well, otherwise the GC will not work.

It's not entirely clear what you're trying to accomplish here, but one option to fix the problem of passing lots of instances around is to use an IoC framework (Ninject is one example, but there are several available to choose from.) Because instances are injected dynamically as your objects are constructed, this can help to reduce inconvenient glue code. There are other patterns available to allow the classes to find eachother (a Singleton instance or some form of Repository that allows lookup of an instance using some identifying data.) It's also possible to use a Message passing design, which strongly decouples the classes, at the cost of some additional overhead.
It really depends on what you're trying to do. Every design will have its pros and cons.

How can I refer to the other class
from here? Do I have to pass the
instance as a parameter?
Yes, the only way to communicate with an instance is to get a reference to it (or an intermediary). Since Locals isn't a static class, pass an instance to an Item constructor or method parameter.

C# Is there any benefit to assigning class properties in the class constructor?

For instance, if I have a class like this:
namespace Sample
{
public Class TestObject
{
private Object MyAwesomeObject = new MyAwesomeObject();
}
}
Is there any benefit to set it up so that the property is set in the constructor like this?
namespace Sample
{
public Class TestObject
{
private Object MyAwesomeObject;
public TestObject()
{
MyAwesomeObject = new MyAwesomeObject()
}
}
}

The two are (nearly) identical.
When you define the initializer inline:
private Object MyAwesomeObject = new MyAwesomeObject();
This will happen prior to the class constructor code. This is often nicer, but does have a couple of limitations.
Setting it up in the constructor lets you use constructor parameters to initialize your members. Often, this is required in order to get more information into your class members.
Also, when you setup values in your constructors, you can use your class data in a static context, which is not possible to do with inlined methods. For example, if you want to initialize something using an expression tree, this often needs to be in a constructor, since the expression tree is in a static context, which will not be allowed to access your class members in an inlined member initializer.

It makes it easier to do step by step debugging
It makes it easier to control the order in which you call constructors
It makes it possible to send parameters to the constructors based on some logic or passed in argument to the object you are working on.

Another nice property of initializing stuff at the declaration site is that doing so on readonly fields guarantees that the field is not observable in its default (initiaized to zero) state.
Here's my article on the subject:
http://blogs.msdn.com/ericlippert/archive/2008/02/18/why-do-initializers-run-in-the-opposite-order-as-constructors-part-two.aspx

The only benefit is that you can be a bit more dynamic in the constructor, where inline initialization requires that you only use static values for constructor arguments and such. For example, if MyAwesomeObject needs the value from a config file, you would have to set that in the constructor

Fields are initialized immediately
before the constructor for the object
instance is called. If the constructor
assigns the value of a field, it will
overwrite any value given during field
declaration.
See Fields (C# Programming Guide).

In your particular example, there's no advantage.
There is, however, lazy instantiation, which reduces your memory footprint in many cases:
namespace Sample
{
public Class TestObject
{
private Object m_MyAwesomeObject;
public TestObject()
{
}
public Object MyAwesomeObject
{
get
{
if (m_MyAwesomeObject == null)
m_MyAwesomeObject = new Object();
return m_MyAwesomeObject;
}
}
}
}

I like to keep all initialization for any class property whether primitive or object in the class constructor(s). Keeps the code easier to read. Easier to debug. Plus the intention of a constructor is to initialize your classes properties.
Also for clients developing against your classes it's nice to make sure that all your properties get a default value and all objects get created. Avoids the NullReferenceExceptions, when a client is using your class. For me putting this all in constructors makes it easier to manage.

I do not like to duplicate code, even if it is among a (hopefully) small number of constructors. To that end I tend to favor inline initialization wherever it makes sense.

Generally, requiring a non-default constructor ensures that the instance is in something other than the default state. This also allows immutable classes, which have their own advantages.

Declaring a Class as a Member of itself

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;