I did my best with the title. What I am trying to accomplish is tiered modularity with dependency injection. Whether or not this design pattern is good is a question for another forum.
Because I am using dependency injection, I have interface/implementation pairs. This is the top-level inteface:
public interface IConfiguration<T> where T : ConfigData
{
T GetConfig();
}
Where ConfigData is a simple class that exposes get/set properties like LogLevel and Environment.
There is a base implementation of the interface:
public abstract class ConfigurationBase<T> : IConfiguration
{
protected ConfigData Config { get; set; }
public T GetConfig()
{
return Config as T;
}
}
Now for the dependency injection part of this! I have several interface/implementation pairs that hierarchically inherit from one another. Furthermore, their protected Config property also exposes more properties in each subsequent child class. Here are my interface/implementation signatures:
public interface IGeneralConfiguration : IConfiguration<GeneralConfigData>
public class GeneralConfiguration : ConfigurationBase<GeneralConfigData>, IGeneralConfiguration
public interface ILoginConfiguration : IConfiguration<LoginConfigData>, IGeneralConfiguration
public class LoginConfiguration : ConfigurationBase<LoginConfigData>, ILoginConfiguration
public interface IAppConfiguration : IConfiguration<AppConfigData>, ILoginConfiguration
public class AppConfiguration : ConfigurationBase<AppConfigData>, IAppConfiguration
Note that the inheritance scheme for the config data element is ConfigData → GeneralConfigData → LoginConfigData → AppConfigData. The config data element just exposes more properties specific to login/the application etc. (like Username or StartUri) in each child.
Now, I can use this configuration concept across all my modules. As far as dependency injection goes, resolving IGeneralConfiguration, ILoginConfiguration or IAppConfiguration will yield the exact same instance. However, now general modules only need to resolve IGeneralConfiguration, modules specific to login will only need to resolve ILoginConfiguration, and app-specific modules can resolve IAppConfiugration, all so that they can access parts of their config data specific to the concern they are trying to handle. This modularity allows me to create smaller side-apps that reuse modules from the main application without having to do a lot of custom coding (for example, I can reuse the login module without the need for referencing app-specific modules) as long as I slightly alter my dependency registration.
If you are still with me up to this point, the only problem with this model is that in all of my sub classes (that inherit from ConfigurationBase<T>), they all need the ConfigData() implementation from the interface above them. This means that class LoginConfiguration needs a method definition for public GeneralConfigData GetConfig(), and class AppConfiguration needs a method defintion for both public GeneralConfigData GetConfig() as well as LoginConfigData GetConfig().
So fine. I do that. Now, in my application-specific modules, I get a compiler error. Up in my class field definitions, I have private IAppConfiguration _appConfiguration;. Later in a method, I make a reference to it:
var element = _appConfiguration.GetConfig().AppSpecificConfigElement;
The compiler is confused, saying
the call is ambiguous between the following or properties 'IConfiguration.GetConfig()' and 'IConfiguration.GetConfig()'
Why doesn't the compiler see that the type is IAppConfiguration and define the call to GetConfig() to the AppConfiguration's GetConfig() (where T is defined as AppConfigData)?
Is there an obvious way to disambiguate the call to GetConfig() using my scheme?
If I understand correctly then what you just did is that you have two methods that have same signature except for the return value which cannot be resolved automatically. Compiler doesn't (and cannot) traverse all subclasses derived from ConfigData to determine that AppSpecificConfigElement belongs to AppConfiguration and pick overload based on that - even if it did you can have multiple classes that have AppSpecificConfigElement property so it won't be much wiser. You need to help compiler understand what you need, either by typing _appConfiguration to proper type or using typed descendant of ConfigData instead of var in your statement first and then get property.
In both cases I think you seriously over-engineered and I would suggest to step back and reconsider your approach. As #zaitsman said these objects should be POCOs and have different loader (DB, filesystem, ...) implementing simple Load/Save interface that can be then passed to DI based on context.
To improve further implementation and to offer some guidelines and keep everything as universal as possible within the project I've created an Interface with a few methods which should be used. However only one method of this class should be visible to the user calling that class so I'd like them to be of the protected variety. E.g
public class ClassThree
{
public ClassThree()
{
var classOne = new ClassOne();
class1.MethodOne();
}
}
This despite ClassOne having 4 methods, 3 methods are used only within the one public class, hence private or protected. These 3 methods are required to make the 4th method work however (in an ideal world other developers would follow the same principle). So I don't want to see the following pop up on intellisense:
class1.MethodTwo();
class1.MethodThree();
class1.MethodFour();
I know one can implicitly call methods from an Interface e.g
IInterface.MethodTwo<Type,Type>(string name)
{
//Do stuff here
}
However I would like to prevent all the casting when calling said methods in ClassOne itself since this is just a thorn in my eye. I like my code clean and this isn't clean at all to me. I've thought of an abstract class however my class is inheriting from another class. With the interface I could just do
public ClassOne : ClassTwo, IInterface<Type1,Type2>
When I do that with an Abstract class however Visual Studio says an interface is expected. Any insights are most welcome and appreciated as I would like to up my code by making my life and that of fellow developers, who have to use my code, easier.
Thanks in advance!
Edit: The scenario is there can be several classes like ClassOne which essentially do the same however they use different types since the objects they have to return hold different values. However the buildup to these objects are more or less the same e.g:
Collect all API data
Retrieve the list to be exported to the API and call #3 or #4 depending on the type.
Export Type 1 to the API
Export Type 2 to the API
The idea is always the same but naturally different API's will require different variables. But to ensure all steps are followed as before I'd like to implement an Interface or something but step 1,2 and 3 should be private or protected and only step 2 should be available to the class that consumed it. However if I only put method 2 in the interface I can never be sure that others will implement 1,3 & 4. And that's kind of the goal here :P. This while ClassOne also inherits from another class and not just the interface.
Edit 2: I know Interfaces only provide public methods which is why I'm looking for alternatives hence this question. I know what is wrong with it I just don't really see how I can get it the way I would like it to be. Thanks for the replies so far!
Edit 3: Interface currently looks like this, I just adjusted variable names for sake of example.
public interface IExport<in T, in TU>
{
void GetRequiredApiData();
bool MethodOne(List<Type> list);
bool ExportOne(T one);
bool ExportTwo(TU two);
bool ValidateExport();
}
The other three methods should just be called inside your public method, or make your first method private/protected and call all 4 inside one public method.
The whole point of an interface is to hide exactly what is problematic for you--the other three methods that the caller doesn't need to know about.
I suspect you need to have those three methods called at separate, specific times, in a specific order. If that's the case then you have a code smell. Those methods are probably just void subroutines that have side effects and change global state. The code needs to be refactored to not be just a series of subroutines and objects need to be broken out differently.
I've built a reusable Class Library to encapsulate my Authentication logic. I want to be able to reuse the compiled *.dll across multiple projects.
What I've got works. But, something about how I'm making the reference, or how my Class Library is structured isn't quite right. And I need your help to figure out what I'm doing-wrong/not-understanding...
I've got a Class Library (Authentication.dll) which is structured like this:
namespace AUTHENTICATION
{
public static class authentication
{
public static Boolean Authenticate(long UserID, long AppID) {...}
//...More Static Methods...//
}
}
In my dependent project I've added a reference to Authentication.dll, and I've added a using directive...
using AUTHENTICATION;
With this structure I can call my Authenticate method, from my dependent project, like so...
authentication.Authenticate(1,1)
I'd like to be able to not have to include that "authentication." before all calls to methods from this Class Library. Is that possible? If so, what changes do I need to make to my Class Library, or how I'm implementing it in my dependent project?
In C# a function cannot exist without a class. So you always need to define something for it, being a class for a static method or an object for an object method.
The only option to achieve that would be to declare a base class in the Authentication assembly from which you inherit in the dependent projects.
You could expose Authenticate as a protected method (or public works too), and call it without specifying the class name.
public class MyClassInDependentProject : authentication
{
public void DoSomething(int userId, long appId)
{
var success = Authenticate(userId, appId);
…
}
}
That said, you'll quickly find this to be a bad design. It conflates a cross-cutting concern with all sorts of other classes, and those classes are now precluded from inheriting from any other class.
Composition is a core principle of object-oriented programming, and we have the idiom "Favor composition over inheritance." This simply means that we break down complexity into manageable chunks (classes, which become instantiated as objects), and then compose those objects together to handle complex processing. So, you have encapsulated some aspect of authentication in your class, and you provide that to other classes compositionally so they can use it for authentication. Thinking about it as an object with which you can do something helps, conceptually.
As an analogy, think about needing to drill a hole in the top of your desk. You bring a drill (object) into your office (class). At that point, it wouldn't make sense to simply say "On," because "On" could be handled by your fan, your lamp, your PC, etc. (other objects in your class). You need to specify, "Drill On."
If you are making a class library in C# you should learn to use the naming conventions that exists: Design Guidelines for Developing Class Libraries
Here is how you should name namespaces: https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/interface
C# is also an object oriented language, hence the need of classes (using Authentication as you should name your class).
It also seems like the data source is hard coded. Your class library users (even if it's just you) might want to configure the data source.
Google about singleton and why it's considered to be an anti pattern today (in most cases).
You are obliged to use Class in order to invoke your method, just
When is static class just NameClass.Method
When is not static, you must create instance, ClassName ob = new ClassName(); ob.Method();
The format of a call like this is class.method, and you really can't escape using the "class" moniker even with the "using" designation. Something has to "host" the function.
I don't think what you are asking for is possible without using the base class method Jay mentioned. If all you want is to simplify the syntax whenever you call Authenticate() however, this silly solution (adding an extra method in each class that needs to do authentication) may be just what you want:
private static void DoAuth(long UserID, long AppID){
authentication.Authenticate(UserID, AppID)
}
If the ID's are always the same within some context, you could also overload it:
private static void DoAuth(){
DoAuth(1,1)
}
Yes, this does mean you have to add more code wherever you want to do the authentication (that's why it's silly! ;) ). It does also however, also reduce this:
authentication.Authenticate(1,1);
...into this:
DoAuth();
I leave the cost / benefit analysis of this up to you..
I know I am some 3 years late but here goes nothing.
To keep your code cleaner and more readable you should create a new namespace for all the re-usable code that you want to have. Then in that namespace have the Authentication Class and Authenticate Function.
To use this you can easily set a using on your namespace and use the function as you are doing like
Authentication.Authenticate()
But to use
Authenticate()
by itself you can always do
using MyNamespace.Authentication;
and in your code use Authenticate Function directly.
I was wondering if someone could give me an overview of why I would use them and what advantage I would gain in the process.
The biggest use of partial classes is to make life easier for code generators / designers. Partial classes allow the generator to simply emit the code they need to emit and they do not have to deal with user edits to the file. Users are likewise free to annotate the class with new members by having a second partial class. This provides a very clean framework for separation of concerns.
A better way to look at it is to see how designers functioned before partial classes. The WinForms designer would spit out all of the code inside of a region with strongly worded comments about not modifying the code. It had to insert all sorts of heuristics to find the generated code for later processing. Now it can simply open the designer.cs file and have a high degree of confidence that it contains only code relevant to the designer.
Another use is to split the implementation of different interfaces, e.g:
partial class MyClass : IF3
{
// main implementation of MyClass
}
partial class MyClass : IF1
{
// implementation of IF1
}
partial class MyClass : IF2
{
// implementation of IF2
}
Aside from the other answers...
I've found them helpful as a stepping-stone in refactoring god-classes. If a class has multiple responsibilities (especially if it's a very large code-file) then I find it beneficial to add 1x partial class per-responsibility as a first-pass for organizing and then refactoring the code.
This helps greatly because it can help with making the code much more readable without actually effecting the executing behavior. It also can help identify when a responsibility is easy to refactor out or is tightly tangled with other aspects.
However--to be clear--this is still bad code, at the end of development you still want one responsibility per-class (NOT per partial class). It's just a stepping-stone :)
Multiple Developer Using Partial Classes multiple developer can work on the same class
easily.
Code Generator Partial classes are mainly used by code generator to keep
different concerns separate
Partial Methods Using Partial Classes you can also define Partial methods as well where a developer can simply define the method and the other developer can implement that.
Partial Method Declaration only Even the code get compiled with method declaration only and if the implementation
of the method isn't present compiler can safely remove that piece of
code and no compile time error will occur.
To verify point 4. Just create a winform project and include this line after the Form1 Constructor and try to compile the code
partial void Ontest(string s);
Here are some points to consider while implementing partial classes:-
Use partial keyword in each part of partial class.
The name of each part of partial class should be the same but the source file name for each part of partial class can be different.
All parts of a partial class should be in the same namespace.
Each part of a partial class should be in the same assembly or DLL, in other words you can't create a partial class in source files from a different class library project.
Each part of a partial class must have the same accessibility. (i.e: private, public or protected)
If you inherit a class or interface on a partial class then it is inherited by all parts of that partial class.
If a part of a partial class is sealed then the entire class will be sealed.
If a part of partial class is abstract then the entire class will be considered an abstract class.
One great use is separating generated code from hand-written code that belong in the same class.
For example since LINQ to SQL uses partial classes you can write your own implementation of certain pieces of functionality (like Many-to-Many relationships) and those pieces of custom code won't get overwritten when you re-generate the code.
The same goes for WinForms code. All the Designer generated code goes in one file that you generally don't touch. Your hand-written code goes in another file. That way, when you change something in Designer, your changes don't get blown away.
It is true that Partial Class is used in auto code generation, one use can be maintaining a large class file which might have thousand lines of code. You never know your class might end up with 10 thousand lines and you don't want to create a new class with different name.
public partial class Product
{
// 50 business logic embedded in methods and properties..
}
public partial class Product
{
// another 50 business logic embedded in methods and properties..
}
//finally compile with product.class file.
Another possible use could be that more than one developer can work on the same class as they are stored at different places. People might laugh but you never know it can be handful sometimes.
Product1.cs
public partial class Product
{
//you are writing the business logic for fast moving product
}
Product2.cs
public partial class Product
{
// Another developer writing some business logic...
}
Hope it makes sense!
Partial classes span multiple files.
How can you use the partial modifier on a C# class declaration?
With partial classes, you can physically separate a class into multiple files. This is often done by code generators.
Example
With normal C# classes, you cannot declare a class in two separate files in the same project. But with the partial modifier, you can.
This is useful if one file is commonly edited and the other is machine-generated or rarely edited.
Here's an example to clarify:
class Program
{
static void Main()
{
A.A1();
A.A2();
}
}
Contents of file A1.cs: C#
using System;
partial class A
{
public static void A1()
{
Console.WriteLine("A1");
}
}
Contents of file A2.cs: C#
using System;
partial class A
{
public static void A2()
{
Console.WriteLine("A2");
}
}
Output:
A1
A2
Partial is required here.
If you remove the partial modifier, you will get an error containing this text:
[The namespace '<global namespace>' already contains a definition for 'A'].
Tip:
To fix this, you can either use the partial keyword, or change one of the class names.
How does the C# compiler deal with partial classes?
If you disassemble the above program (using IL Disassembler), you will see that the files A1.cs and A2.cs are eliminated. You will find that the class A is present.
Class A will contain the methods A1 and A2 in the same code block. The two classes were merged into one.
Compiled result of A1.cs and A2.cs: C#
internal class A
{
// Methods
public static void A1()
{
Console.WriteLine("A1");
}
public static void A2()
{
Console.WriteLine("A2");
}
}
Summary
Partial classes can simplify certain C# programming situations.
They are often used in Visual Studio when creating Windows Forms/WPF programs.
The machine-generated C# code is separate.
Or You could find the whole description here.
keep everything as clean as possible when working with huge classes, or when working on a team, you can edit without overriding (or always commiting changes)
The main use for partial classes is with generated code. If you look at the WPF (Windows Presentation Foundation) network, you define your UI with markup (XML). That markup is compiled into partial classes. You fill in code with partial classes of your own.
As an alternative to pre-compiler directives.
If you use pre-compiler directives (namely #IF DEBUG) then you end up with some gnarly looking code intermingled with your actual Release code.
You can create a seperate partial-class to contain this code, and either wrap the entire partial class in a directive, or omit that code-file from being sent to the compiler (effectively doing the same).
If you have a sufficiently large class that doesn't lend itself to effective refactoring, separating it into multiple files helps keep things organized.
For instance, if you have a database for a site containing a discussion forum and a products system, and you don't want to create two different providers classes (NOT the same thing as a proxy class, just to be clear), you can create a single partial class in different files, like
MyProvider.cs - core logic
MyProvider.Forum.cs - methods pertaining specifically to the forum
MyProvider.Product.cs - methods for products
It's just another way to keep things organized.
Also, as others have said, it's about the only way to add methods to a generated class without running the risk of having your additions destroyed the next time the class is regenerated. This comes in handy with template-generated (T4) code, ORMs, etc.
Most people remark that partial should only be used for a class that has a generated code file or for interfaces. I disagree, and here is why.
For one example, let's look at the C# System.Math class... that's class. I would not attempt to stuff 70+ methods all into the same single code file. It would be a nightmare to maintain.
Placing each math method into individual partial class files, and all code files into a Math folder in the project, would be significantly cleaner organization.
The same could/would hold true for many other classes that have a large amount of diverse functionality. For example a class for managing the PrivateProfile API might benefit by being split into a clean set of partial class files in a single project folder.
Personally, I also split what most people call "helper" or "utility" classes into individual partial files for each method or method functional group. For example on one project the string helper class has almost 50 methods. That would be a long unwieldy code file even using regions. It is significantly easier to maintain using individual partial class files for each method.
I would just be careful using partial classes and keep all code file layout consistent throughout the project when doing this. Such as placing any class public enums and class private members into a Common.cs or similarly named file in the folder, instead of spreading them out across the files unless they are specific to only the partial file they are contained in.
Keep in mind that when you split a class into separate files you also lose the ability to use the text editor splitter bar that lets you view two different sections of a current file simultaneously.
Another use i saw is,
Extending a big abstract class regarding data access logic ,
i have various files with names Post.cs,Comment.cs,Pages.cs...
in Post.cs
public partial class XMLDAO :BigAbstractClass
{
// CRUD methods of post..
}
in Comment.cs
public partial class XMLDAO :BigAbstractClass
{
// CRUD methods of comment..
}
in Pages.cs
public partial class XMLDAO :BigAbstractClass
{
// CRUD methods of Pages..
}
Service references are another example where partial classes are useful to separate generated code from user-created code.
You can "extend" the service classes without having them overwritten when you update the service reference.
Partial classes make it possible to add functionality to a suitably-designed program merely by adding source files. For example, a file-import program could be designed so that one could add different types of known files by adding modules that handle them. For example, the main file type converter could include a small class:
Partial Public Class zzFileConverterRegistrar
Event Register(ByVal mainConverter as zzFileConverter)
Sub registerAll(ByVal mainConverter as zzFileConverter)
RaiseEvent Register(mainConverter)
End Sub
End Class
Each module that wishes to register one or more types of file converter could include something like:
Partial Public Class zzFileConverterRegistrar
Private Sub RegisterGif(ByVal mainConverter as zzFileConverter) Handles Me.Register
mainConverter.RegisterConverter("GIF", GifConverter.NewFactory))
End Sub
End Class
Note that the main file converter class isn't "exposed"--it just exposes a little stub class that add-in modules can hook to. There is a slight risk of naming conflicts, but if each add-in module's "register" routine is named according to the type of file it deals with, they probably shouldn't pose a problem. One could stick a GUID in the name of the registration subroutine if one were worried about such things.
Edit/Addendum
To be clear, the purpose of this is to provide a means by which a variety of separate classes can let a main program or class know about them. The only thing the main file converter will do with zzFileConverterRegistrar is create one instance of it and call the registerAll method which will fire the Register event. Any module that wants to hook that event can execute arbitrary code in response to it (that's the whole idea) but there isn't anything a module could do by improperly extending the zzFileConverterRegistrar class other than define a method whose name matches that of something else. It would certainly be possible for one improperly-written extension to break another improperly-written extension, but the solution for that is for anyone who doesn't want his extension broken to simply write it properly.
One could, without using partial classes, have a bit of code somewhere within the main file converter class, which looked like:
RegisterConverter("GIF", GifConvertor.NewFactory)
RegisterConverter("BMP", BmpConvertor.NewFactory)
RegisterConverter("JPEG", JpegConvertor.NewFactory)
but adding another converter module would require going into that part of the converter code and adding the new converter to the list. Using partial methods, that is no longer necessary--all converters will get included automatically.
Partial classes recently helped with source control where multiple developers were adding to one file where new methods were added into the same part of the file (automated by Resharper).
These pushes to git caused merge conflicts. I found no way to tell the merge tool to take the new methods as a complete code block.
Partial classes in this respect allows for developers to stick to a version of their file, and we can merge them back in later by hand.
example -
MainClass.cs - holds fields, constructor, etc
MainClass1.cs - a developers new code as they implement
MainClass2.cs - is another developers class for their new code.
From MSDN:
1.At compile time, attributes of partial-type definitions are merged. For example, consider the following declarations:
[SerializableAttribute]
partial class Moon { }
[ObsoleteAttribute]
partial class Moon { }
They are equivalent to the following declarations:
[SerializableAttribute]
[ObsoleteAttribute]
class Moon { }
The following are merged from all the partial-type definitions:
XML comments
interfaces
generic-type parameter attributes
class attributes
members
2.Another thing, nested partial classes can be also partial:
partial class ClassWithNestedClass
{
partial class NestedClass { }
}
partial class ClassWithNestedClass
{
partial class NestedClass { }
}
Here is a list of some of the advantages of partial classes.
You can separate UI design code and business logic code so that it is easy to read and understand. For example you are developing an web application using Visual Studio and add a new web form then there are two source files, "aspx.cs" and "aspx.designer.cs" . These two files have the same class with the partial keyword. The ".aspx.cs" class has the business logic code while "aspx.designer.cs" has user interface control definition.
When working with automatically generated source, the code can be added to the class without having to recreate the source file. For example you are working with LINQ to SQL and create a DBML file. Now when you drag and drop a table it creates a partial class in designer.cs and all table columns have properties in the class. You need more columns in this table to bind on the UI grid but you don't want to add a new column to the database table so you can create a separate source file for this class that has a new property for that column and it will be a partial class. So that does affect the mapping between database table and DBML entity but you can easily get an extra field. It means you can write the code on your own without messing with the system generated code.
More than one developer can simultaneously write the code for the class.
You can maintain your application better by compacting large classes. Suppose you have a class that has multiple interfaces so you can create multiple source files depending on interface implements. It is easy to understand and maintain an interface implemented on which the source file has a partial class.
I find it disturbing that the word 'cohesion' does not appear anywhere in these posts (until now).
And I'm also disturbed that anyone thinks enabling or encouraging huge classes and methods is somehow a good thing.
If you're trying to understand and maintain a code-base 'partial' sucks.
Whenever I have a class that contains a nested class that is of any significant size/complexity, I mark the class as partial and put the nested class in a separate file. I name the file containing the nested class using the rule: [class name].[nested class name].cs.
The following MSDN blog explains using partial classes with nested classes for maintainability: http://blogs.msdn.com/b/marcelolr/archive/2009/04/13/using-partial-classes-with-nested-classes-for-maintainability.aspx
I know this question is really old but I would just like to add my take on partial classes.
One reason that I personally use partial classes is when I'm creating bindings for a program, especially state machines.
For example, OpenGL is a state machine, there are heaps of methods that can all be changed globally, however, in my experience binding something similar to OpenGL where there are so many methods, the class can easily exceed 10k LOC.
Partial classes will break this down for me and help me with finding methods quickly.
Partial classes are primarily introduced to help Code generators, so we (users) don't end up loosing all our work / changes to the generated classes like ASP.NET's .designer.cs class each time we regenerate, almost all new tools that generate code LINQ, EntityFrameworks, ASP.NET use partial classes for generated code, so we can safely add or alter logic of these generated codes taking advantage of Partial classes and methods, but be very carefully before you add stuff to the generated code using Partial classes its easier if we break the build but worst if we introduce runtime errors. For more details check this https://web.archive.org/web/20211020111732/https://www.4guysfromrolla.com/articles/071509-1.aspx
I note two usages which I couldn't find explicitly in the answers.
Grouping Class Items
Some developers use comments to separate different "parts" of their class. For example, a team might use the following convention:
public class MyClass{
//Member variables
//Constructors
//Properties
//Methods
}
With partial classes, we can go a step further, and split the sections into separate files. As a convention, a team might suffix each file with the section corresponding to it. So in the above we would have something like: MyClassMembers.cs, MyClassConstructors.cs, MyClassProperties.cs, MyClassMethods.cs.
As other answers alluded to, whether or not it's worth splitting the class up probably depends on how big the class is in this case. If it's small, it's probably easier to have everything in one master class. But if any of those sections get too big, its content can be moved to a separate partial class, in order to keep the master class neat. A convention in that case might be to leave a comment in saying something like "See partial class" after the section heading e.g.:
//Methods - See partial class
Managing Scope of Using statements / Namespace
This is probably a rare occurrence, but there might be a namespace collision between two functions from libraries that you want to use. In a single class, you could at most use a using clause for one of these. For the other you'd need a fully qualified name or an alias. With partial classes, since each namespace & using statements list is different, one could separate the two sets of functions into two separate files.
What is and how can it be used in C#.
Can you use the same concept in Python/Perl?
A partial type (it doesn't have to be a class; structs and interfaces can be partial too) is basically a single type which has its code spread across multiple files.
The main use for this is to allow a code generator (e.g. a Visual Studio designer) to "own" one file, while hand-written code is put in another.
I've no idea whether Python/Perl have the same capabilities, I'm afraid.
The c# partial class has been already explained here so I'll just cover the python part. You can use multiple inheritance to elegantly distribute the definition of a class.
class A_part1:
def m1(self):
print "m1"
class A_part2:
def m2(self):
print "m2"
class A(A_part1, A_part2):
pass
a = A()
a.m1()
a.m2()
A partial class is simply a class that's contained in more than one file. Sometimes it's so that one part can be machine-generated, and another part user-edited.
I use them in C# when I'm making a class that's getting a bit too large. I'll put the accessors and constructors in one file, and all of the interesting methods in a different file.
In Perl, you'd simply have two (or more) files that each declare themselves to be in a package:
(main program)
use MyClass;
(in MyClass.pm)
use MyClassOtherStuff;
package MyClass;
# [..class code here...]
(in MyClassOtherStuff.pm)
package MyClass;
# [...rest of code here...]
The concept of partial types have already been explained.
This can be done in python. As an example, do the following in a python shell.
class A(object):
pass
obj = A()
def _some_method(self):
print self.__class__
A.identify = _some_method
obj.identify()
Because python is a dynamic language you don't need a concept like partial class. In python is possible to extend object with functionality in runtime so it possible to break class declaration into different files
A Partial type is a type whose declaration is separated across multiple files. It makes sense to use them if you have a big class, which is hard to handle and read for a typical developer, to separate that class definition in separate files and to put in each file a logically separated section of code (for instance all public methods and proprieties in one file, private in other, db handling code in third and so on..)
No you don't have the same syntactical element in Python.
Python also has meta classes but that is more like a template class than a partial class. A good example of meta class usage is the Django ORM. All of your table models inherit from a base model class which also gets functionality included from a meta class. It is a pretty cool concept that enables an active record like pattern (is it full active record?).
Partial class comes handy when you have auto-generated code by some tool. Refer question Project structure for Schema First Service Development using WCF for an example.
You can put your logic in the partial class. Even if the auto-generated file is destroyed and recreated, your logic will persist in the partial class.