Extending class definitions with partial classes in C# .NET

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()

		partial void PayWithCard()

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()

		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();

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.


About Andras Nemes
I'm a .NET/Java developer living and working in Stockholm, Sweden.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Elliot Balynn's Blog

A directory of wonderful thoughts

Software Engineering

Web development

Disparate Opinions

Various tidbits

chsakell's Blog


Once Upon a Camayoc

Bite-size insight on Cyber Security for the not too technical.

%d bloggers like this: