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