One of the more controversial additions to C# is partial methods. A partial method is usually defined in a partial class file and is optionally implemented in the regular class file. If the partial method is not implemented, the compiler strips out all mention of it.
Partial methods are heavily restricted. They must be private, cannot return a value, and cannot have out parameters. These restrictions are necessary because any calls to a partial method that was not implemented are simply ignored. This in turn means it cannot be used as a definite assignment to a variable. Visual Basic also has partial methods and though VB does not require definite assignments for variables, it has the same restrictions.
With all these restrictions, one has to ask, "What are they good for?" Well basically, they are only used by code generators for a sort of lightweight event handling. As Alexander Jung explains
The usual (probably the only relevant) use case for partial methods is light weight event handling in combination with code generation. Say, you parse a database or an XML file and generate data classes. Tens of classes, hundreds of properties, all fairly generic, boilerplate stuff. And also fairly common is the need to interfere with this method for validation or that property setter to update another one. So instead of manipulating the generated code or having hundreds of events and thousands of method calls during runtime (of which in most cases only a tiny fraction will actually do something) partial methods kick in. They are easier to declare and use than events (pay for what you need) and if not used they simply vanish (pay as you go).
This performance boost is not free. Because of the restriction that partial methods must be private, Alexander has uncovered these flaws.
The con: If you like metadata driven applications (and already struggled with ASP.NET databinding because there is no way to attach meta data)… well, prepare for some further loss of information. If you need some event for any property setter (for tracing or tracking), if you need any kind of dynamic behaviour (e.g. to attach some kind of generic rules engine), … let’s just hope the developer of the code generator anticipated that use case (or prepare for some work). You have a clean layer separation and the entities should know nothing about the UI? Well, put your code right into the data class will spoil that. But hey, you might use partial methods to implement real events. Manually.
Other people are likewise concerned about partial methods in C#. Most of these concerns come from the use of code designers. Stefan Wenig writes
First, because I'm not a big fan of designers. I'm quite worried they'll soon enough be sending us down the same road that COM-based development went in its last years, with hundreds of designers and wizards that generated ATL and MCF code nobody ever wanted to read. The Ruby crowd will be laughing their asses off with a few lines of source where we'll be stuck with designers and generated files and complicated build processes. (Compare that to COM/C++ vs. Java in the late 90s!) Wasn't C# about code-based developer productivity in the first place (vs. VB's designer-driven RAD road map)? You should be the last to care about the whims of the designer-based, enterprise-library-minded, software-factory-code-generator-happy folk. Resist!
Ayende Rahien is even less kind,
Let us corrupt C# for code generators: The horror story of partial methods