I was wondering if someone could give me an overview of why I would use them and what advantage I would gain in the process.
相关问题
- Sorting 3 numbers without branching [closed]
- Graphics.DrawImage() - Throws out of memory except
- Why am I getting UnauthorizedAccessException on th
- 求获取指定qq 资料的方法
- How to know full paths to DLL's from .csproj f
Service references are another example where partial classes are useful to separate generated code from user-created code.
You can "extend" the service classes without having them overwritten when you update the service reference.
Partial classes span multiple files.
How can you use the partial modifier on a C# class declaration?
With partial, you can physically separate a class into multiple files.
This is often done by code generators.
Example
With normal C# classes, you cannot declare a class in two separate files in the same project.
But with the partial modifier, you can.
This is useful if one file is commonly edited and the other is machine-generated or rarely edited.
An Example will clear your concept.
Partial is required here.
If you remove the partial modifier, you will get an error containing this text: [The namespace '<global namespace>' already contains a definition for 'A'].
Tip: To fix this, you can either use the partial keyword, or change one of the class names.
How does the C# compiler deal with partial classes?
If you disassemble the above program, you will see that the files A1.cs and A2.cs are eliminated.
You will find that the class A is present.
IL Disassembler So: Class A will contain the methods A1 and A2 in the same code block. The two classes were merged into one.
Compiled result of A1.cs and A2.cs: C#
Summary
Partial classes can simplify certain C# programming situations.
They are often used in Visual Studio when creating Windows Forms/WPF programs.
The machine-generated C# code is separate.
Or You could find the whole Description here .
As an alternative to pre-compiler directives.
If you use pre-compiler directives (namely
#IF DEBUG
) then you end up with some gnarly looking code intermingled with your actual Release code.You can create a seperate partial-class to contain this code, and either wrap the entire partial class in a directive, or omit that code-file from being sent to the compiler (effectively doing the same).
If you have a sufficiently large class that doesn't lend itself to effective refactoring, separating it into multiple files helps keep things organized.
For instance, if you have a database for a site containing a discussion forum and a products system, and you don't want to create two different providers classes (NOT the same thing as a proxy class, just to be clear), you can create a single partial class in different files, like
MyProvider.cs - core logic
MyProvider.Forum.cs - methods pertaining specifically to the forum
MyProvider.Product.cs - methods for products
It's just another way to keep things organized.
Also, as others have said, it's about the only way to add methods to a generated class without running the risk of having your additions destroyed the next time the class is regenerated. This comes in handy with template-generated (T4) code, ORMs, etc.
Partial classes make it possible to add functionality to a suitably-designed program merely by adding source files. For example, a file-import program could be designed so that one could add different types of known files by adding modules that handle them. For example, the main file type converter could include a small class:
Each module that wishes to register one or more types of file converter could include something like:
Note that the main file converter class isn't "exposed"--it just exposes a little stub class that add-in modules can hook to. There is a slight risk of naming conflicts, but if each add-in module's "register" routine is named according to the type of file it deals with, they probably shouldn't pose a problem. One could stick a GUID in the name of the registration subroutine if one were worried about such things.
Edit/Addendum To be clear, the purpose of this is to provide a means by which a variety of separate classes can let a main program or class know about them. The only thing the main file converter will do with zzFileConverterRegistrar is create one instance of it and call the registerAll method which will fire the Register event. Any module that wants to hook that event can execute arbitrary code in response to it (that's the whole idea) but there isn't anything a module could do by improperly extending the zzFileConverterRegistrar class other than define a method whose name matches that of something else. It would certainly be possible for one improperly-written extension to break another improperly-written extension, but the solution for that is for anyone who doesn't want his extension broken to simply write it properly.
One could, without using partial classes, have a bit of code somewhere within the main file converter class, which looked like:
but adding another converter module would require going into that part of the converter code and adding the new converter to the list. Using partial methods, that is no longer necessary--all converters will get included automatically.
Partial classes recently helped with source control where multiple developers were adding to one file where new methods were added into the same part of the file (automated by Resharper).
These pushes to git caused merge conflicts. I found no way to tell the merge tool to take the new methods as a complete code block.
Partial classes in this respect allows for developers to stick to a version of their file, and we can merge them back in later by hand.
example -