Should partial methods be included in C #?

There are many controversies in C # 's new features, and the partial approach (Partial method) is one. A partial method is usually defined in a partial class and can be implemented in a regular class file. If the partial methods are not implemented, the compiler will not compile them.

There are strict limitations to the partial approach. They must be private, cannot return values, and cannot have output parameters. Because any calls to partial methods that are not implemented are simply ignored, it is necessary to say these limitations. This in turn means that a partial method cannot be an explicitly assigned variable. Visual Basic also has a partial approach, and although VB does not need to assign a variable explicitly, it has the same limitations.

With so many restrictions, one might ask, "What are their advantages?" ”。 This is a good question, basically, the partial method is only used by the code generator when handling lightweight events. As Alexander Jung explains:

The scenario where partial methods are usually (and possibly only relevant) is used to handle lightweight events when code is generated. If you parse a database or an XML file and then generate a data class, you'll find dozens of classes, hundreds of attributes, and a whole bunch of generics and template files. Partial methods Another area that is often used is validation, or letting the setter of a property update another attribute. So if you want to use the generated code, or if there are hundreds of events and thousands of method calls at run time (in fact, in most cases only a little bit of it), let the partial approach come! Partial methods are much easier to declare and use than events, and they disappear if they are not used.

Performance improvements are not without cost. From the limitations that the partial methods must be private, Alexander found their deficiencies:

Disadvantage: If you like metadata-driven applications, and have been plagued by asp.net data bindings (because there is no other way to attach metadata) ... Then, be prepared to lose information in the future! If you need to add events for the setter of the attribute (based on tracking and debugging needs), if you need a dynamic behavior (such as attaching a generic rule engine) and so on, let's pray that the developer of the Code Analyzer can predict the scenario (or be prepared). You have a clear layer of separation, so should the entity be ignorant of the UI? Yes, putting the code directly into the data class destroys the layer's relationships, but you can manually implement the real event with a partial approach!

Others are also worried about the partial approach in C #, mostly about the use of code designers. Stefan Wenig wrote:

First of all, I'm not very keen on designers. What worries me is that designers may soon be sending us to the old way of COM development, where hundreds of of designers and wizards generate so many ATL and Mcf code that no one wants to see. As we get bogged down in designers, unwanted files, and complex build processes, the guys using Ruby are laughing because they can work with a few lines of code (reminiscent of the 90 com/c++ and Java comparisons of the last century). Is the productivity of code-based developers not the primary concern of C # (see VB's designer-driven rad roadmap)? We should no longer be immersed in the illusion of a designer-based, enterprise-class library that is happy to use the Software Factory code designer. Unite and resist them!

Ayende Rahien also has no Zuiruan:

Let's bury these code designers together, put up the brilliant tombstone of the partial method!