Partial Classes

Partial class

A partial class, or partial type, is a feature of some object oriented computer programming languages in which the declaration of a class may be split across multiple source-code files, or multiple places within a single file.


The purpose of partial classes is to allow a class's definition to span across multiple files. It is especially useful for:

  • Very large classes (where it is cumbersome to navigate with an editor through a single file)
  • Separation of concerns, in a way similar to aspect-oriented programming but without using any extra tools. An example is shown below.
  • Allowing multiple developers to work on a single class at the same time without the need for later merging files in source control.
  • Allowing a separation between the class interface and the implementation-related definitions (Separate definitions of the public and private parts)
  • Easing the writing of code generators, such as visual designers. This is perhaps the most useful reason. It is a challenge to develop code generators that can manage the generated code when it is placed in the human-written code:
    • Requires a lot of parsing of unnecessary code, just to find a place to insert the generated code. Altering the code is also a problem. Poorly written generators hold the potential risk of damaging the entire file.
    • Human programmers tend not to like the looks of generated code, and thus like to "tweak and tune" it, so it looks better, conforms to their standards, or is better optimized. All in all, it's best not to let human-programmers see the code at all.

Using partial classes, the code generator processes a separate file, and is thus alleviated from all the above mentioned problems.


The implementation of partial classes is quite straight-forward and architecture-transparent. When compiling, the compiler performs a phase of precompilation: first it "unifies" all the parts of the partial class into one logical class, and from that point, normal compilation takes off.


Simple example in VB.NET

This simple example, written in Visual Basic .NET, shows how parts of the same class are defined in two different files.file1.vb: Partial Class MyClass
   Private _name As String
End Class file2.vb: Partial Class MyClass
   Public Readonly Property Name() As String
            Return _name
        End Get
   End Property
End Class When compiled, the result is the same as if the two files were written as one, like this: Class MyClass
   Private _name As String
   Public Readonly Property Name() As String
            Return _name
        End Get
   End Property
End Class

Separation of concerns

Partial classes also support the separation of concerns . The following Bear class has different aspects implemented in different parts.Bear_Hunting.cs: public partial class Bear {
  private IEdible Hunt()
      // returns food...
} } Bear_Eating.cs: public partial class Bear {
  private int Eat(IEdible food)
      return food.Nutrition.Value;
} } Bear_Hunger.cs: public partial class Bear {
  private int hunger;
  public void MonitorHunger()
       // Here we can refer to members of the other partial definitions
       if(hunger > 50)
           hunger -= this.Eat(this.Hunt());
} } For example, if we want to compile a version without support for hunger management (it could be a feature that costs extra for your customers), we simply remove the partial declaration in Bear_Hunger.cs.

Now if a program also supported hunger management in other classes all those partial class definitions could go in a separate 'Hunger' directory. This is what is usually called multidimensional separation of concerns, and it helps programmers update the code and add new features, even the first time anyone started working with this code.

Separation of concerns in Ruby

bear_hunting.rb class Bear
 def hunt
   # TODO: return some food
end bear_eating.rb
class Bear
  def eat(food )
raise "#{food} is not edible!" unless food.respond_to? :nutrition_value
bear_hunger.rb class Bear
 attr_accessor :hunger
 def monitor_hunger
   if @hunger > 50 then
     @hunger -= )


The usage of partial classes is subject of criticism and thus not broadly adopted in object oriented languages and rarely used in older programming languages like Smalltalk or C++.

  • Partial classes break the concept of a class being a single entity with a single concern. Partial classes change that concept and introduce parts of classes being a single entity with a single concern.
  • Partial classes will likely lead to large classes in different files but with many concerns - such classes are generally hard to understand and to be avoided to reduce maintenance efforts.
  • Separation of concerns should preferably be done by separating concerns in single classes. If classes (made up of several partial classes) have several concerns they will have to be touched & deployed whenever such a concern changes
  • Partial classes try to solve problems that are already solved by other more sophisticated means:
    • Revision control systems allow multiple developers to work simultaneously on a single class - if they don't touch the same method (as with partial classes) they don't need to merge.
    • Interfaces are used to separate a classes interface from its implementation
    • Code generators, such as visual designers should generate code that is independent of manually written code - i.e. they generate classes that have not to be touched by developers. Developers just hook up to these classes using common techniques like events, dependency injection or simply derivation
    • Aspect oriented programming allows to separate concerns that are usually not easily separated by conventional means. AOP does this on a much deeper level than partial classes e.g. even allowing to extract concerns like logging or transaction handling out of the methods.


External links

Search another word or see Partial Classeson Dictionary | Thesaurus |Spanish
Copyright © 2015, LLC. All rights reserved.
  • Please Login or Sign Up to use the Recent Searches feature