When should I use the Partial keyword?

Question

I was reading the MSDN article on the Partial keyword, and this part caught my eye:

The partial keyword indicates that other parts of the class, struct, or interface can be defined in the namespace. All the parts must use the partial keyword. All the parts must be available at compile time to form the final type. All the parts must have the same accessibility, such as public, private, and so on.

[...]

All the parts that specify a base class must agree, but parts that omit a base class still inherit the base type. Parts can specify different base interfaces, and the final type implements all the interfaces listed by all the partial declarations. Any class, struct, or interface members declared in a partial definition are available to all the other parts. The final type is the combination of all the parts at compile time.

I had two questions regarding this concept:

• Firstly, it seems that this is a way to bypass the lack of multiple inheritance in C# (aside from interfaces, of course). Are there any repercussions to doing so, aside from normal multiple inheritance issues, such as the Diamond Problem? Basically, just because I can, does it mean I should?

• Secondly, when exactly should I split up files? Just by reading this, it feels like I should be able to declare a nested class in its own file, and partial it together with the containing class, and thereby improve readability. Is this the point of Partial, or should it only be used as described in the above article?

Answer 1

Firstly, it seems that this is a way to bypass the lack of multiple inheritance in C# (aside from interfaces, of course). Are there any repercussions to doing so, aside from normal multiple inheritance issues, such as the Diamond Problem? Basically, just because I can, does it mean I should?

It doesn't do multiple inheritance. It's actually way more evil, since it exposes private variables -- but at the same time it doesn't introduce diamonds. Try the following code to see what I mean:

public class Test0
{
    protected int bar;

    public void Unexpected() { Console.WriteLine("3. {0}", bar); }
}

public partial class Test1
{
    private int foo;

    public void Foo() { Console.WriteLine("1. {0}", foo); bar = 1; }
}

public partial class Test1 : Test0
{
    public void Bar() { Console.WriteLine("2. {0}", foo); foo = 1; }
}

class Driver
{
    public static void Main()
    {
        var t1 = new Test1();
        t1.Bar();
        t1.Foo();
        t1.Unexpected();
        Console.ReadLine();
    }
} 

In other words, you should be very careful with variables.

Secondly, when exactly should I split up files? Just by reading this, it feels like I should be able to declare a nested class in its own file, and partial it together with the containing class, and thereby improve readability. Is this the point of Partial, or should it only be used as described in the above article?

Code generation is a well known example. I personally use partial classes a lot when dealing with the Facade pattern (which is very useful when creating WCF/SOAP services). In most cases I try to avoid it for the above reason.

Answer 2

Firstly, this has nothing to do with multiple inheritance in C#. It simply allows you to split a class' implementation between files. A regular class in C# can implement multiple interfaces as well, so you're not gaining anything by using partial classes.

Secondly, partial classes are the most useful when part of a class' implementation is generated by some tool and the other portion is written by a developer. This allows you to re-generated the generated portion of the code without losing the hand coded portion of the implementation.

Answer 3

partial classes have nothing to do with multiple inheritance. the only very good reason to use them is when part of the class is generated and the other is your own.

Answer 4

No, it mentions base interfaces, not concrete types, so multiple inheritance still isn't possible. For your second point, the main reason was to allow generation tools to create a partial which hides many of the implementation details from the partial that the developer edits.