I have been reading Programming Microsoft® Visual C#® 2008: The Language to get a better understanding of C# and what can be done with it. I came across partial classes which I had already encountered from ASP.Net's Page class.
To me it seems that you can do what partial classes do with an abstract class and an overridden one. Obviously one team will be in control of the interface via the abstract methods but you would be relying on each other anyway. And if the goal is collaboration then isn't that what source control and other tools solve.
I am just missing the point to a partial class. Also could someone provide a real world use.
Partial classes have nothing to do with object inheritance. Partial classes are just a way of splitting the source code that defines a class into separate files (this is for example done when you create a new form in your Windows Forms application - one file is "your" code, another file .designer.cs contains the code that VS2008 manages for you).
A good usage example is when one side of the partial class is generated (such as an ORM)
The great thing about a partial class is that you can take an existing class and add on to it. Now this sounds a lot like inheritance, but there are a lot of things that inheritance can't do that partial classes will.
Here's one think about the Linq to SQL classes generated for you. They are autogenerated meaning you shouldn't modify them. Without a partial class, you can't attach an interface.
You could create a new class and derive that from the Linq to sql class, but that really doesn't get you anything because you can't upcast the linq to sql class to your class with the interface.
Partial classes should be restricted to using with auto-generated code, where the other code cannot be modified. Using it as a substitute for inheritance or adding functionality are not best practices.
If you have a large class, its already wrong. Code should be refactored into multiple "real" classes instead of multiple files. Large classes in general signifies the class is doing too many things and violates SRP (Single Responsibility Principle).
Partial class are now used heavily in ASP.Net to allow two source files the mark-up based example.aspx and the code based example.aspx.cs so that methods and variable defined in each are visible to each.
in the example.aspx
<custom:exampleControl id="exampleCntr" property="<%#getProperty()%>" />
in the example.aspx.cs
private object GetProperty(){ // called from aspx
return DateTime.Now;
}
private void DoStuff(){
ExampleControl c = exampleCntr; //exampleCntr is defined in aspx.
}
The bi-directional nature of this cannot be recreated with abstract classes.
It sounds like your question is what the difference is between
partial class Foo
{
PART ONE
}
partial class Foo
{
PART TWO
}
and
astract class FooBase
{
PART ONE
}
partial class Foo : FooBase
{
PART TWO
}
While they may appear somewhat similar, and in some cases the latter construct could be used in place of the former, there are at least two problems with the latter style:
-1- The type FooBase would likely have to know the identity of the concrete type which was supposed to derive from it, and always use variables of that type, rather than of type FooBase. That represents an uncomfortably-close coupling between the two types.
-2- If type Foo is public, type FooBase would have to also be public. Even if all the constructors of FooBase are internal, it would be possible for outside code to define classes which derived from FooBase but not Foo; constructing instances of such classes would be difficult, but not impossible.
If it were possible for a derived type to expand the visibility of a base type, these issues wouldn't be overly problematical; one would regard FooBase as a "throwaway" identifier which would appear exactly twice: once in its declaration, and once on the declaration line for Foo, and figure that every FooBase would be a Foo in disguise. The fact that FooBase could not use Foo instance members on this without a typecast could be irksome, but could also encourage a good partitioning of code. Since it isn't possible to expand the visibility of a base type, however, the abstract-class design seems icky.
Purpose of partial classes is to allow a class's definition to span across multiple files. This can allow better maintainability and separation of your code.
We use partial classes to split up our larger classes. That way it's easier to check out a part of the code with Sourcesafe. This limits the cases where four developers need to access the same file.
