Extending class definitions with partial classes in C# .NET
February 25, 2016 Leave a comment
The ‘partial’ keyword helps you divide your classes into multiple files within the same namespace. One obvious usage of partial classes is to split the definition of a large type into smaller chunks. You cannot just use the partial keyword with classes but methods as well.
The partial classes will reside in two – or more – different cs files in the same namespace. Say you have a partial Customer class in the project-name/domains folder:
namespace Various.PartialTypes { public partial class Customer { public void PerformBuy() { Console.WriteLine("Buying..."); } partial void PayWithCard() { Console.WriteLine("Paying..."); } } }
You cannot of course enter another file called Customer.cs in the same location on disk but you can put one in another folder, e.g. project-name/extended:
namespace Various.PartialTypes { public partial class Customer { public void Pay() { PayWithCard(); } partial void PayWithCard(); } }
Make sure that the namespaces are the same in the two partial class declarations. Note how the partial method PayWithCard is declared in this second example and implemented in the first one. Partial methods cannot have access modifiers such as “public”. You won’t be able to access it externally like this:
Customer c = new Customer(); c.PayWithCard();
The compiler will complain that PayWithCard cannot be accessed due to its protection level. Partial methods are implicitly private. In addition, they are void, they cannot return anything otherwise you’ll get a compiler error. It’s OK to only have the declaration of a partial method without an implementation. Partial methods are optional, they only indicate the possibility of building on them, it’s not a must. If a partial method is not implemented anywhere in the partial class then the compiler will ignore it.
Note that this is not the same as inheritance with base and derived classes.
A well-known example of partial classes is auto-generated code. If you used EntityFramework before then you know that it generates partial classes based on your SQL tables like this:
public partial class Customer : EntityObject
Any time you refresh the generated code the EF designer file is rewritten. Therefore it’s not a good idea to put your custom code within dbcontext.designer.cs directly as it will disappear whenever you refresh your database objects. Create a partial Customer class elsewhere in the project, declare the same namespace and your custom code will be safe. You can extend the functionality of the auto-generated types as you wish: add new properties, methods, fields etc.
View all various C# language feature related posts here.