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:Partial Class MyClass Private _name As StringEnd Class;file2.vb:Partial Class MyClass Public Readonly Property Name() As String Get Return _name End Get End PropertyEnd ClassWhen 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 Get Return _name End Get End PropertyEnd Class

Separation of concerns

Partial classes also support the separation of concerns [cite web
url=http://ptsoft.net/tdd/papers/TDIAS06_HyperNet__MDSOC_support_for_NET.pdf
title=Hyper/Net: MDSoC Support for .NET
author=Tiago Dias
date=October 2006
accessdate=2007-09-25
work=DSOA 2006] . 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.

eparation of concerns in Ruby

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

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 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.

References

External links

*