anonymity …
Contrary to the obvious, the title means something quite different in the following context … :P
Just so that I might not forget how I did this, I log here, a way to achieve anonymous classes in C# ( a feature quite inexplicably missing from the language!
Now, C# obviously supports anonymous methods albeit via a twisted mechanism using delegates ( Java surprisingly doesn’t support anonymous methods … anyone wants to bring out a superset language, this is the time!! ).
In the following trivial scenario, one has an interface, consisting of 2 methods, which can be dynamically (anonymously) instantiated by any other class. Let’s consider Java here, so that the shortcoming in C# is multiplied, and my solution seems worthwhile! :)
For instance:
public interface MyInterface
{
public void Method1( Object value );
public Object Method2();
}
Say, I have another class: consists a method accepting an object of our interface defined above.
For instance:
public class HungryClass
{
MyInterface _myObject; public void HungryMethod( MyInterface myObject )
{
// for lack of anything else interesting
_myObject = myObject;
}
}
Now, I have my lazy class, consisting of a lazy method in charge of supplying the object (of our interface) above.
- For instance:
public class LazyClass
{
public void LazyMethod()
{
// Call hungry method as it's hungry
HungryMethod(
new MyInterface()
{
public void Method1( Object value )
{
// blah ...
}
public Object Method2()
{
// bleh ...
}
}
);
}
}
Well, the point of the above loquacity was obviously to show that anonymous classes (as in the LazyMethod()) is an option, and in most big programs, can be a huge pain reliever (especially, in massive auto-generated files).
C# DOESN’T SUPPORT ANONYMOUS CLASSES.
Since C# doesn’t support anonymous classes, you need to create a dummy concrete class every time we want to pass an object of the interface.
For instance:
public DummyMyInterface : MyInterface
{
public void Method1( Object value )
{
// blah ...
}
public Object Method2()
{
// bleh ...
}
}
and then pass an object of this class. Can you imagine creating a huge set of such concrete classes when the need occurs, especially in the auto-generated case. Well, if you can’t … trust me, it’s a major pain in the .. ahem .. fingers.
SOLUTION: (voi la!)
In order to support the same, I use delegates in C# (similar to function pointers in C, C++). The point lies in understanding that delegates themselves are types, and we can define variables of the same. And delegates are the only way in which you can achieve any kind of anonymity in C# (anonymous methods). Put 2 and 2 together, in addition to getting 4, you also get the following:
In C#, you define MyInterface as follows:
public class MyInterface
{
// Delegates for as many methods (with similar signatures ofcourse)
public delegate void Method1Delegate( Object value );
public delegate Object Method2Delegate(); // Define variables for each of the above (delegate) types
Method1Delegate _m1;
Method2Delegate _m2;// Default Constructor (unfortunate adherence)
public MyInterface()
{
_m1 = null;
_m2 = null;
}// Parametrized Constructor (the crux)
public MyInterface( Method1Delegate m1, Method2Delegate m2 )
{
_m1 = m1;
_m2 = m2;
}// In order to maintain consistency (backward compatibility) with the
// existing system, define the following virtual functions.
public virtual void Method1( Object value )
{
// Just in case the delegate wasn't defined
if ( _m1 == null )
throw new Exception( "method undefined" );_m1( value ); // delegatize baby !
}
public virtual Object Method2()
{
// Just in case the delegate wasn't defined
if ( _m2 == null )
throw new Exception( "method undefined" );return _m2(); // delegatize baby !
}
}
Now, our lazy class looks like this:
————————————–
public class LazyClass
{
public void LazyMethod()
{
// Call hungry method as it's hungry
HungryMethod(
new MyInterface()
{
delegate( Object value )
{
// blah ...
},
delegate()
{
// bleh ...
}
}
);
}
}
Because of the above instantiation, our delegates will be correctly instantiated. And whenever invokes the methods, Method1 & Method2, oblivious of the underlying implementation, the correct behavior will be exhibited (since those methods are in turn defined to invoke the delegates). Also, it’s obvious from the above that any class can also choose to override the default behaviour of our virtual methods. Hence, reduced pain, good looking code (aha, subjective eh?), and less code change propogation (if any at all) throughout the code base!
If the guys reading have a cleaner solution, let me know, and you’ll have the opportunity to change my code base yourself ! … :)
