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.

Purpose

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.

Implementation

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.

Examples

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

<source lang="vbnet"> Partial Class MyClass

   Private _name As String

End Class </source>

file2.vb

<source lang="vbnet"> Partial Class MyClass

   Public Readonly Property Name() As String
        Get
            Return _name
        End Get
   End Property

End Class </source> When compiled, the result is the same as if the two files were written as one, like this: <source lang="vbnet"> Class MyClass

   Private _name As String
   Public Readonly Property Name() As String
        Get
            Return _name
        End Get
   End Property

End Class </source>

Separation of concerns

Partial classes enforce separation of concerns . The following Bear class, written in C#, has different aspects implemented in different parts.

Bear_Hunting.cs

<source lang="csharp"> public partial class Bear {

  private IEdible Hunt()
  {
      // returns food...
  }

} </source>

Bear_Eating.cs

<source lang="csharp"> public partial class Bear {

  private int Eat(IEdible food)
  {
      return food.Nutrition.Value;
  }

} </source>

Bear_Hunger.cs

<source lang="csharp"> 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());
  }

} </source> 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

<source lang="ruby"> class Bear

 def hunt
   # TODO: return some food
 end

end </source>

bear_eating.rb

<source lang="ruby">

class Bear
  def eat( food )
    raise "#{food} is not edible!" unless food.respond_to? :nutrition_value
    food.nutrition_value
  end
end

</source>

bear_hunger.rb

<source lang="ruby"> class Bear

 attr_accessor :hunger
 def monitor_hunger
   if @hunger > 50 then
     @hunger -= self.eat( self.hunt )
   end
 end

end </source>

Criticism

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 class's 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

• Dias, Tiago (October 2006). ""Programming demo - .NET using Partial Types for better code"". [{{|{{| http://www.pubmedcentral.nih.gov/articlerender.fcgi?tool=pmcentrez&artid={{{}}}

                     }}}} Hyper/Net]. Youtube. http://www.youtube.com/watch?v=oaw8K8GNhAI.