rhugghed
August 30th, 2006, 03:31 AM
hi, im a graduating computer science student from University of Santo Tomas. our RSS filtering proposal was rejected by our thesis adviser so we're planning of doing a C# related thesis instead.
upon our research, we saw these information. these are faults in the C# language. can you suggest anything about these informations that i can turn into a thesis proposal? we're really in bad need of a thesis proposal. any help, or suggestion would be highly appreciated. thanks :)
http://www.veridicus.com/tummy/programming/dotnetshame.asp
I love .NET. It has some great features and some welcome improvements over Java. However, when .NET goes wrong, it goes VERY wrong. This page is dedicated to the huge ** that (I think) Microsoft "engineers" have made.
This page is here in the hope that it will draw enough attention to force Microsoft into fixing the problems in .NET V2. (Probably not going to happen though *sigh*).
.NET was designed with OO in mind, but I think someone forgot to tell the guys who wrote the base class library. Maybe Microsoft should have called the base class library the highly-coupled, not-so-cohesive, not-so-common class library ;-).
Some of you might be interested to know that I was a big Microsoft supporter for years. Once upon a time, before Java 1.2, Microsoft had the most popular and well supported object-based architecture around (COM) and I loved them for it.
I now have a comparison of Java and C#/.NET here.
C#
Problem:
No anonymous inner classes. Anonymous inner classes are the OO equivalent of lambda abstractions and can be very powerful.
C# features type-safe function pointers called delegates but has NO concept of anonymous inner delegates. This makes Java's event handling with anonymous inner classes much more convenient than C#'s named delegates.
Solution:
Add support for inner and anonymous inner classes (J# supports them! Jesus!) as well as anonymous methods.
The syntax for anonymous methods could look like this:
public MyForm()
{
this.Click += new EventHandler(object sender, EventArgs eventArgs)
{
Close();
};
}
The code without anonymous methods would look like this:
public MyForm()
{
this.Click += new EventHandler(MyClickHandler);
}
private void MyClickHandler(object sender, EventArgs eventArgs)
{
Close();
}
It may not look impressive but trust me, many event handlers are only one line long and writing a member function for each handler isn't pretty. Making event handler methods part of the class often makes no sense because the event handling code often has no context outside of the method that adds the handler. Classes are often less cohesive when they contain event handlers as top level methods. Anonymous methods increase encapsulation and localises the method to the area where it is used.
[Update: 18 November 2002: Microsoft have announced that a future version of C# will include support for anonymous methods.]
It will probably be a cold day in hell before Microsoft adds support for anonymous inner classes. The reason is simple, Java has them and "newbie" Java developers love to complain about how confusing they are. Microsoft will not add the feature in an attempt to gain respect from the developers who are confused by the language feature in Java.
Anonymous inner classes (like anonymous methods) increases encapsulation and cohesion and would make a good addition to C#.
Problem:
The syntax for using structs and classes look the same but, semantically, they can mean very different things.
e.g. The following code will behave differently depending on whether or not Point is a class or struct.
Point point1 = new Point(10, 10);
Point point2 = point1;
point2.X = 20;
Console.WriteLine(point1.X);
If Point is a struct, changing point2.X won't have an effect on point1.X. This IMO is the most fundamental flaw in C#.
Solution:
One solution would be to require the use of the struct keyword when referring to value types. Intrinsic value types (int, short, long, etc) can ignore this requirement.
public static void Foo(struct Point p)
{
// I can see that p is a struct so I know I have a copy and not a reference.
p.x = 20;
}
public static void Main()
{
// I know p is stack allocated because I'm using 'new struct' instead of 'new'.
struct Point p = new struct Point(10, 10);
// I can see that p is a struct so I know I'm passing Foo() a copy of p.
Foo(p);
}
Using the struct keyword also conveniently eliminates the confusion that C++ programmers have over the use of the new keyword to construct value types [In C++ new is used to allocate objects on the heap -- never the stack]. This solution is so obvious (especially when you consider C#'s C++ ancestry), elegant and unobtrusive that it's amazing that Microsoft missed or dismissed it.
http://www.25hoursaday.com/CsharpVsJava.html#wishlist
Wish You Were Here
Checked Exceptions
Before the advent of exceptions, most error handling was done via return codes. There are many advantages of exceptions over return codes that are typically touted including the fact that exceptions
provide a consistent means to handle errors and other exceptional conditions.
enable an error to propagate up the call stack if not handled in the current context.
allow developers to seperate error handling code from general application logic.
Java creates an additional wrinkle by possessing both checked and unchecked exceptions. Checked exceptions are exceptions that the calling method must handle either by catching the exception or declaring that the exception should be handled by its calling method via the throws clause. On the other hand, unchecked exceptions (also called runtime exceptions) do not have to be caught or declared in the throws clause. In a sense unchecked exceptions are similar to return codes in that they can be ignored without warnings or errors being issued by the compiler. Although if an exception is ignored at runtime, your program will terminate.
Checked exceptions are typically used to indicate to a calling method that the callee failed in its task as well as pass information as to how and why it failed. One must either catch a checked exception or declare it in the throws clause of the method or the Java compiler will issue an error. The reasoning behind the fact that the exception must be declared in the throws clause is that handling whatever errors that can occur when the method is used is just as important as knowing what parameters it accepts and the kind of type it returns.
Unchecked exceptions are typically exceptions that can occur in most parts of the program and thus the overhead of explicitly checking for them outweighs their usefulness due to the massive code bloat that would ensue. Examples of situations that throw unchecked exceptions are accessing a null object reference, trying to access an out of bounds index of an array or a division by zero. In all of the aforementioned cases it would be cumbersome to put try...catch blocks around every the code (for instance a try...catch block around every object access or every array access) and they are better off as unchecked exceptions.
In C#, all exceptions are unchecked and there is no analog to the throws clause. One major side effect of this is that unless the creator of the API explicitly documents the exceptions thrown then it is not possible for the users of the API to know what exceptions to catch in their code leading to unrobust applications that can fail unexpectedly. Thus users of C# are reliant on the documentation skill of programmers as their primary error handling mechanism which is a less than optimal situation.
For instance in the following code snippet, the only way to know what exceptions can be thrown by the method below is to either have the source code for all the methods called within it or if the developer of the method documents all the exceptions thrown by all the methods called within it (meaning that the developers of those methods must have done the same ad infinitum).
C# Code
public string GetMessageFromServer(string server)
{
//Set up variables and String to write to the server
Encoding ASCII = Encoding.ASCII;
string Get = "GET / HTTP/1.1\r\nHost: " + server +
"\r\nConnection: Close\r\n\r\n";
Byte[] ByteGet = ASCII.GetBytes(Get);
Byte[] RecvBytes = new Byte[256];
String strRetPage = null;
// IPAddress and IPEndPoint represent the endpoint that will
// receive the request
// Get first IPAddress in list return by DNS
IPAddress hostadd = Dns.Resolve(server).AddressList[0];
IPEndPoint EPhost = new IPEndPoint(hostadd, 80);
//Create the Socket for sending data over TCP
Socket s = new Socket(AddressFamily.InterNetwork, SocketType.Stream,
ProtocolType.Tcp );
// Connect to host using IPEndPoint
s.Connect(EPhost);
if (!s.Connected)
{
strRetPage = "Unable to connect to host";
return strRetPage;
}
// Sent the GET text to the host
s.Send(ByteGet, ByteGet.Length, 0);
// Receive the page, loop until all bytes are received
Int32 bytes = s.Receive(RecvBytes, RecvBytes.Length, 0);
strRetPage = "Default HTML page on " + server + ":\r\n";
strRetPage = strRetPage + ASCII.GetString(RecvBytes, 0, bytes);
while (bytes > 0)
{
bytes = s.Receive(RecvBytes, RecvBytes.Length, 0);
strRetPage = strRetPage + ASCII.GetString(RecvBytes, 0, bytes);
}
return strRetPage;
}
The above code snippet is from the .NET Framework Beta 2 documentation for the Socket class. Note how there no exceptions caught in the code. If this was a method in a real application as opposed to a sample, it would be impossible for the users of this method to know what exceptions to catch without access to the source code or without the author of the method painstakingly checking what exceptions are thrown by every single method called and then documenting them. Below is the list of exceptions that could be thrown within the method according to their entries in the Microsoft .NET framework Beta 2 documentation.
Method Exception(s) thrown
Encoding.GetBytes ArgumentNullException
Dns.Resolve ArgumentNullException, SocketException
IPEndPoint constructor ArgumentException
Socket constructor SocketException
Socket.Connect ArgumentNullException, SocketException
Socket.Receive ArgumentNullException, SocketException
ASCII.GetString [undocumented as of Beta 2]
If the author of the method does not have time to document the exceptions that may be thrown from this method or happens to leave out an important one, such as the SocketException in this case, then the users of the method could have their applications fail unexpectedly without an elegant means of recovery in place. In the above case, the main exception of interest to users would probably be the SocketException since the others are all related to the internal workings of the method and don't really have anything to do with the caller and in fact would probably be unchecked exceptions if they existed in Java. In practice the GetMessageFromServer method would check the validity of its string parameter and throw ArgumentNException or one of its subclasses depending the results of the check.
The rationale for excluding checked exceptions from C# has never been fully explained by Microsoft but this message from Eric Gunnerson of the C# team sheds some light on the reasoning behind this decision. The primary reason for this choice according to Gunnerson is that examination of small programs led to the conclusion that using checked exceptions could both enhance developer productivity and enhance code quality. On the other hand experience with large software projects suggested that using checked exceptions decreased productivity with little or no increase in code quality.
[updated 12/5/2001] It should be noted that there is agreement amongst some Java developers with Eric Gunnerson's assertion that checked exceptions have certain disadvantages. Alan Griffiths wrote an excellent article entitled Exceptional Java where he notes that checked exceptions lead to breaking encapsulation, loss of information and information overload. Bruce Eckel, author of Thinking In Java and Thinking In C++, also questions the wisdom of checked exceptions in his article entitled Does Java need Checked Exceptions?.
The lack of checked exceptions in C# will be very unsettling for Java developers and may lead to program designs which are flawed. One only has to remember the anecdote about how originally a considerable amount of the exceptions in the Java API were unchecked but upon changing them to checked exceptions a number of bugs and design flaws were found in the API. Hopefully this will be remedied in later versions of C# or a third party could develop a static source code analysis tool such as lint. Meanwhile C# developers must take care to document all exceptions thrown from their methods that callers should be aware of as a matter of consideration. This is not to say that documentation should not typically exist but since it is the only means to ensure exception safe C# code then its importance is now a much greater.
Cross Platform Portability (Write Once, Run Anywhere)
Dynamic Class Loading
The ability to dynamically load classes at runtime in Java is a very powerful feature especially when combined with a remote procedure call mechanism. Dynamic class loading enables Java applications to download the class files (i.e. byte codes) of classes that do not exist on the target machine. An object type that only exists on one machine can be transferred to other machines in a seamless and transparent manner. Thus new types can be introduced on a remote machine which allows the behavior of remote applications to be significantly extended at runtime. The following example shows an example of a remote application that accepts types that implement a certain interface, IStockTicker.
Java Code
public class MyRMIServer extends UnicastRemoteObject
implements SomeInterface {
public MyRMIServer() throws RemoteException{ super();}
public String obtainName(IStockTicker ticker){
String stock_ticker = ticker.getTicker();
if(stock_ticker.equalsIgnoreCase("MSFT"))
return "Microsoft Corporation";
else if(stock_ticker.equalsIgnoreCase("SUNW"))
return "Sun Microsystems";
else
return "Unknown Stock Ticker";
}_/* obtainName(IStockTicker) */
}
The obtainName() remote method in the above class accepts types that implement the IStockTicker interface. It is possible for this method to be invoked from a remote client which then passes a type that implements IStockTicker, for example NASDAQStock, that does not exist on the server where the MyRMIServer class lives. In this case the entire code needed for NASDAQStock class is transmitted from the client to the remote server automatically.
C# and the .NET Remoting mechanism also enable remotely downloading classes from one machine to the other but the client has to publish the assembly and the server can then load it via a URL.
For information on Java Remote Method Invokation (RMI) read the Java tutorial on RMI. Information on .NET Remoting with C# is explained in this introduction to .NET remoting and this technical overview on MSDN.
Interfaces That Contain Fields
In Java it is possible for constants to be declared in interfaces which are then available to implementing classes while in C# this is not allowed. This may not be a big issue in C# since the primary usage of constants declared in interfaces is as a poor emulation of enumerations.
Anonymous Inner Classes
An anonymous inner class is a class declaration that occurs at the same point where an instance of that class is created. Anonymous inner classes are typically used where only one instance of a type will exist in the application. The most popular usage of anonymous inner classes is for specifying callbacks especially in the Java GUI libraries but there are other situations where anonymous inner classes are beneficial as well. Below is an example of using anonymous inner classes to implement the State Design Pattern.
http://www.csharphelp.com/archives/archive65.html?printable=yes
Jump To C# (Excerpt)
By Vyas Bharghava
4. Anonymous Classes
There are no anonymous classes in C#
5. Classes inside Methods
Not available in C#
upon our research, we saw these information. these are faults in the C# language. can you suggest anything about these informations that i can turn into a thesis proposal? we're really in bad need of a thesis proposal. any help, or suggestion would be highly appreciated. thanks :)
http://www.veridicus.com/tummy/programming/dotnetshame.asp
I love .NET. It has some great features and some welcome improvements over Java. However, when .NET goes wrong, it goes VERY wrong. This page is dedicated to the huge ** that (I think) Microsoft "engineers" have made.
This page is here in the hope that it will draw enough attention to force Microsoft into fixing the problems in .NET V2. (Probably not going to happen though *sigh*).
.NET was designed with OO in mind, but I think someone forgot to tell the guys who wrote the base class library. Maybe Microsoft should have called the base class library the highly-coupled, not-so-cohesive, not-so-common class library ;-).
Some of you might be interested to know that I was a big Microsoft supporter for years. Once upon a time, before Java 1.2, Microsoft had the most popular and well supported object-based architecture around (COM) and I loved them for it.
I now have a comparison of Java and C#/.NET here.
C#
Problem:
No anonymous inner classes. Anonymous inner classes are the OO equivalent of lambda abstractions and can be very powerful.
C# features type-safe function pointers called delegates but has NO concept of anonymous inner delegates. This makes Java's event handling with anonymous inner classes much more convenient than C#'s named delegates.
Solution:
Add support for inner and anonymous inner classes (J# supports them! Jesus!) as well as anonymous methods.
The syntax for anonymous methods could look like this:
public MyForm()
{
this.Click += new EventHandler(object sender, EventArgs eventArgs)
{
Close();
};
}
The code without anonymous methods would look like this:
public MyForm()
{
this.Click += new EventHandler(MyClickHandler);
}
private void MyClickHandler(object sender, EventArgs eventArgs)
{
Close();
}
It may not look impressive but trust me, many event handlers are only one line long and writing a member function for each handler isn't pretty. Making event handler methods part of the class often makes no sense because the event handling code often has no context outside of the method that adds the handler. Classes are often less cohesive when they contain event handlers as top level methods. Anonymous methods increase encapsulation and localises the method to the area where it is used.
[Update: 18 November 2002: Microsoft have announced that a future version of C# will include support for anonymous methods.]
It will probably be a cold day in hell before Microsoft adds support for anonymous inner classes. The reason is simple, Java has them and "newbie" Java developers love to complain about how confusing they are. Microsoft will not add the feature in an attempt to gain respect from the developers who are confused by the language feature in Java.
Anonymous inner classes (like anonymous methods) increases encapsulation and cohesion and would make a good addition to C#.
Problem:
The syntax for using structs and classes look the same but, semantically, they can mean very different things.
e.g. The following code will behave differently depending on whether or not Point is a class or struct.
Point point1 = new Point(10, 10);
Point point2 = point1;
point2.X = 20;
Console.WriteLine(point1.X);
If Point is a struct, changing point2.X won't have an effect on point1.X. This IMO is the most fundamental flaw in C#.
Solution:
One solution would be to require the use of the struct keyword when referring to value types. Intrinsic value types (int, short, long, etc) can ignore this requirement.
public static void Foo(struct Point p)
{
// I can see that p is a struct so I know I have a copy and not a reference.
p.x = 20;
}
public static void Main()
{
// I know p is stack allocated because I'm using 'new struct' instead of 'new'.
struct Point p = new struct Point(10, 10);
// I can see that p is a struct so I know I'm passing Foo() a copy of p.
Foo(p);
}
Using the struct keyword also conveniently eliminates the confusion that C++ programmers have over the use of the new keyword to construct value types [In C++ new is used to allocate objects on the heap -- never the stack]. This solution is so obvious (especially when you consider C#'s C++ ancestry), elegant and unobtrusive that it's amazing that Microsoft missed or dismissed it.
http://www.25hoursaday.com/CsharpVsJava.html#wishlist
Wish You Were Here
Checked Exceptions
Before the advent of exceptions, most error handling was done via return codes. There are many advantages of exceptions over return codes that are typically touted including the fact that exceptions
provide a consistent means to handle errors and other exceptional conditions.
enable an error to propagate up the call stack if not handled in the current context.
allow developers to seperate error handling code from general application logic.
Java creates an additional wrinkle by possessing both checked and unchecked exceptions. Checked exceptions are exceptions that the calling method must handle either by catching the exception or declaring that the exception should be handled by its calling method via the throws clause. On the other hand, unchecked exceptions (also called runtime exceptions) do not have to be caught or declared in the throws clause. In a sense unchecked exceptions are similar to return codes in that they can be ignored without warnings or errors being issued by the compiler. Although if an exception is ignored at runtime, your program will terminate.
Checked exceptions are typically used to indicate to a calling method that the callee failed in its task as well as pass information as to how and why it failed. One must either catch a checked exception or declare it in the throws clause of the method or the Java compiler will issue an error. The reasoning behind the fact that the exception must be declared in the throws clause is that handling whatever errors that can occur when the method is used is just as important as knowing what parameters it accepts and the kind of type it returns.
Unchecked exceptions are typically exceptions that can occur in most parts of the program and thus the overhead of explicitly checking for them outweighs their usefulness due to the massive code bloat that would ensue. Examples of situations that throw unchecked exceptions are accessing a null object reference, trying to access an out of bounds index of an array or a division by zero. In all of the aforementioned cases it would be cumbersome to put try...catch blocks around every the code (for instance a try...catch block around every object access or every array access) and they are better off as unchecked exceptions.
In C#, all exceptions are unchecked and there is no analog to the throws clause. One major side effect of this is that unless the creator of the API explicitly documents the exceptions thrown then it is not possible for the users of the API to know what exceptions to catch in their code leading to unrobust applications that can fail unexpectedly. Thus users of C# are reliant on the documentation skill of programmers as their primary error handling mechanism which is a less than optimal situation.
For instance in the following code snippet, the only way to know what exceptions can be thrown by the method below is to either have the source code for all the methods called within it or if the developer of the method documents all the exceptions thrown by all the methods called within it (meaning that the developers of those methods must have done the same ad infinitum).
C# Code
public string GetMessageFromServer(string server)
{
//Set up variables and String to write to the server
Encoding ASCII = Encoding.ASCII;
string Get = "GET / HTTP/1.1\r\nHost: " + server +
"\r\nConnection: Close\r\n\r\n";
Byte[] ByteGet = ASCII.GetBytes(Get);
Byte[] RecvBytes = new Byte[256];
String strRetPage = null;
// IPAddress and IPEndPoint represent the endpoint that will
// receive the request
// Get first IPAddress in list return by DNS
IPAddress hostadd = Dns.Resolve(server).AddressList[0];
IPEndPoint EPhost = new IPEndPoint(hostadd, 80);
//Create the Socket for sending data over TCP
Socket s = new Socket(AddressFamily.InterNetwork, SocketType.Stream,
ProtocolType.Tcp );
// Connect to host using IPEndPoint
s.Connect(EPhost);
if (!s.Connected)
{
strRetPage = "Unable to connect to host";
return strRetPage;
}
// Sent the GET text to the host
s.Send(ByteGet, ByteGet.Length, 0);
// Receive the page, loop until all bytes are received
Int32 bytes = s.Receive(RecvBytes, RecvBytes.Length, 0);
strRetPage = "Default HTML page on " + server + ":\r\n";
strRetPage = strRetPage + ASCII.GetString(RecvBytes, 0, bytes);
while (bytes > 0)
{
bytes = s.Receive(RecvBytes, RecvBytes.Length, 0);
strRetPage = strRetPage + ASCII.GetString(RecvBytes, 0, bytes);
}
return strRetPage;
}
The above code snippet is from the .NET Framework Beta 2 documentation for the Socket class. Note how there no exceptions caught in the code. If this was a method in a real application as opposed to a sample, it would be impossible for the users of this method to know what exceptions to catch without access to the source code or without the author of the method painstakingly checking what exceptions are thrown by every single method called and then documenting them. Below is the list of exceptions that could be thrown within the method according to their entries in the Microsoft .NET framework Beta 2 documentation.
Method Exception(s) thrown
Encoding.GetBytes ArgumentNullException
Dns.Resolve ArgumentNullException, SocketException
IPEndPoint constructor ArgumentException
Socket constructor SocketException
Socket.Connect ArgumentNullException, SocketException
Socket.Receive ArgumentNullException, SocketException
ASCII.GetString [undocumented as of Beta 2]
If the author of the method does not have time to document the exceptions that may be thrown from this method or happens to leave out an important one, such as the SocketException in this case, then the users of the method could have their applications fail unexpectedly without an elegant means of recovery in place. In the above case, the main exception of interest to users would probably be the SocketException since the others are all related to the internal workings of the method and don't really have anything to do with the caller and in fact would probably be unchecked exceptions if they existed in Java. In practice the GetMessageFromServer method would check the validity of its string parameter and throw ArgumentNException or one of its subclasses depending the results of the check.
The rationale for excluding checked exceptions from C# has never been fully explained by Microsoft but this message from Eric Gunnerson of the C# team sheds some light on the reasoning behind this decision. The primary reason for this choice according to Gunnerson is that examination of small programs led to the conclusion that using checked exceptions could both enhance developer productivity and enhance code quality. On the other hand experience with large software projects suggested that using checked exceptions decreased productivity with little or no increase in code quality.
[updated 12/5/2001] It should be noted that there is agreement amongst some Java developers with Eric Gunnerson's assertion that checked exceptions have certain disadvantages. Alan Griffiths wrote an excellent article entitled Exceptional Java where he notes that checked exceptions lead to breaking encapsulation, loss of information and information overload. Bruce Eckel, author of Thinking In Java and Thinking In C++, also questions the wisdom of checked exceptions in his article entitled Does Java need Checked Exceptions?.
The lack of checked exceptions in C# will be very unsettling for Java developers and may lead to program designs which are flawed. One only has to remember the anecdote about how originally a considerable amount of the exceptions in the Java API were unchecked but upon changing them to checked exceptions a number of bugs and design flaws were found in the API. Hopefully this will be remedied in later versions of C# or a third party could develop a static source code analysis tool such as lint. Meanwhile C# developers must take care to document all exceptions thrown from their methods that callers should be aware of as a matter of consideration. This is not to say that documentation should not typically exist but since it is the only means to ensure exception safe C# code then its importance is now a much greater.
Cross Platform Portability (Write Once, Run Anywhere)
Dynamic Class Loading
The ability to dynamically load classes at runtime in Java is a very powerful feature especially when combined with a remote procedure call mechanism. Dynamic class loading enables Java applications to download the class files (i.e. byte codes) of classes that do not exist on the target machine. An object type that only exists on one machine can be transferred to other machines in a seamless and transparent manner. Thus new types can be introduced on a remote machine which allows the behavior of remote applications to be significantly extended at runtime. The following example shows an example of a remote application that accepts types that implement a certain interface, IStockTicker.
Java Code
public class MyRMIServer extends UnicastRemoteObject
implements SomeInterface {
public MyRMIServer() throws RemoteException{ super();}
public String obtainName(IStockTicker ticker){
String stock_ticker = ticker.getTicker();
if(stock_ticker.equalsIgnoreCase("MSFT"))
return "Microsoft Corporation";
else if(stock_ticker.equalsIgnoreCase("SUNW"))
return "Sun Microsystems";
else
return "Unknown Stock Ticker";
}_/* obtainName(IStockTicker) */
}
The obtainName() remote method in the above class accepts types that implement the IStockTicker interface. It is possible for this method to be invoked from a remote client which then passes a type that implements IStockTicker, for example NASDAQStock, that does not exist on the server where the MyRMIServer class lives. In this case the entire code needed for NASDAQStock class is transmitted from the client to the remote server automatically.
C# and the .NET Remoting mechanism also enable remotely downloading classes from one machine to the other but the client has to publish the assembly and the server can then load it via a URL.
For information on Java Remote Method Invokation (RMI) read the Java tutorial on RMI. Information on .NET Remoting with C# is explained in this introduction to .NET remoting and this technical overview on MSDN.
Interfaces That Contain Fields
In Java it is possible for constants to be declared in interfaces which are then available to implementing classes while in C# this is not allowed. This may not be a big issue in C# since the primary usage of constants declared in interfaces is as a poor emulation of enumerations.
Anonymous Inner Classes
An anonymous inner class is a class declaration that occurs at the same point where an instance of that class is created. Anonymous inner classes are typically used where only one instance of a type will exist in the application. The most popular usage of anonymous inner classes is for specifying callbacks especially in the Java GUI libraries but there are other situations where anonymous inner classes are beneficial as well. Below is an example of using anonymous inner classes to implement the State Design Pattern.
http://www.csharphelp.com/archives/archive65.html?printable=yes
Jump To C# (Excerpt)
By Vyas Bharghava
4. Anonymous Classes
There are no anonymous classes in C#
5. Classes inside Methods
Not available in C#