Imagine the following scenario in a Xamarin solution:
Assembly A (PCL):
public abstract class MyBaseClass
{
public MyBaseClass()
{
[...]
}
[...]
}
Assembly B (3rd Party Library):
public class SomeLibClass
{
[...]
public void MethodThatCreatesClass(Type classType){
[...]
//I want to allow this to work
var obj = Activator.CreateInstance(classType);
[...]
}
[...]
}
Assembly C (Main project):
public class ClassImplA:MyBaseClass{
[...]
}
public class ClassImplA:MyBaseClass{
[...]
}
public class TheProblem{
public void AnExample(){
[...]
//I want to block these instantiations for this Assembly and any other with subclasses of MyBaseClass
var obj1 = new ClassImplA()
var obj2 = new ClassImplB()
[...]
}
}
How can I prevent the subclasses from being instantiated on their own assembly and allow them only on the super class and the 3rd Party Library (using Activator.CreateInstance)?
Attempt 1
I though I could make the base class with an internal constructor but then, I saw how silly that was because the subclasses wouldn't be able to inherit the constructor and so they wouldn't be able to inherit from the superclass.
Attempt 2
I tried using Assembly.GetCallingAssembly on the base class, but that is not available on PCL projects. The solution I found was to call it through reflection but it also didn't work since the result of that on the base class would be the Assembly C for both cases (and I think that's because who calls the constructor of MyBaseClass is indeed the default constructors of ClassImplA and ClassImplB for both cases).
Any other idea of how to do this? Or am I missing something here?
Update
The idea is to have the the PCL assembly abstract the main project (and some other projects) from offline synchronization.
Given that, my PCL uses its own DB for caching and what I want is to provide only a single instance for each record of the DB (so that when a property changes, all assigned variables will have that value and I can ensure that since no one on the main project will be able to create those classes and they will be provided to the variables by a manager class which will handle the single instantions).
Since I'm using SQLite-net for that and since it requires each instance to have an empty constructor, I need a way to only allow the SQLite and the PCL assemblies to create those subclasses declared on the main project(s) assembly(ies)
Update 2
I have no problem if the solution to this can be bypassed with Reflection because my main focus is to prevent people of doing new ClassImplA on the main project by simple mistake. However if possible I would like to have that so that stuff like JsonConvert.DeserializeObject<ClassImplA> would in fact fail with an exception.
I may be wrong but none of the access modifiers will allow you to express such constraints - they restrict what other entities can see, but once they see it, they can use it.
You may try to use StackTrace class inside the base class's constructor to check who is calling it:
public class Base
{
public Base()
{
Console.WriteLine(
new StackTrace()
.GetFrame(1)
.GetMethod()
.DeclaringType
.Assembly
.FullName);
}
}
public class Derived : Base
{
public Derived() { }
}
With a bit of special cases handling it will probably work with Activator class , but isn't the best solution for obvious reasons (reflection, error-prone string/assembly handling).
Or you may use some dependency that is required to do anything of substance, and that dependency can only be provided by your main assembly:
public interface ICritical
{
// Required to do any real job
IntPtr CriticalHandle { get; }
}
public class Base
{
public Base(ICritical critical)
{
if (!(critical is MyOnlyTrueImplementation))
throw ...
}
}
public class Derived : Base
{
// They can't have a constructor without ICritical and you can check that you are getting you own ICritical implementation.
public Derived(ICritical critical) : base(critical)
{ }
}
Well, other assemblies may provide their implementations of ICritical, but yours is the only one that will do any good.
Don't try to prevent entity creation - make it impossible to use entities created in improper way.
Assuming that you can control all classes that produce and consume such entities, you can make sure that only properly created entities can be used.
It can be a primitive entity tracking mechanism, or even some dynamic proxy wrapping
public class Context : IDisposable
{
private HashSet<Object> _entities;
public TEntity Create<TEntity>()
{
var entity = ThirdPartyLib.Create(typeof(TEntity));
_entities.Add(entity);
return entity;
}
public void Save<TEntity>(TEntity entity)
{
if (!_entities.Contains(entity))
throw new InvalidOperationException();
...;
}
}
It won't help to prevent all errors, but any attempt to persist "illegal" entities will blow up in the face, clearly indicating that one is doing something wrong.
Just document it as a system particularity and leave it as it is.
One can't always create a non-leaky abstraction (actually one basically never can). And in this case it seems that solving this problem is either nontrivial, or bad for performance, or both at the same time.
So instead of brooding on those issues, we can just document that all entities should be created through the special classes. Directly instantiated objects are not guaranteed to work correctly with the rest of the system.
It may look bad, but take, for example, Entity Framework with its gotchas in Lazy-Loading, proxy objects, detached entities and so on. And that is a well-known mature library.
I don't argue that you shouldn't try something better, but that is still an option you can always resort to.
I was thinking about designing a proper contract for future plugins creation for an application I'm currently working on. Basically the idea is to define an interface, but I want the application to be aware of plugins that currently presented to the system and to show the user a nice list of plugins with their names and a brief descriptions which ofcourse the developer of the plugin should provide, the user of the application shouldn't be able to alter this easily so an additional config file is not an option. I don't want to use the class name of filename of the assembly for this. Also I think that it should be accessable without instantiating the plugin, but maybe through reflection, something like: assembly.GetType(type).GetProperty("Name").GetValue(null, null).ToString();. Ofcourse I could provide some logic to check for existance something like if(assembly.GetType(type).GetProperty("Name") != null), but this is not a good idea either, because if the property does not exist the end user won't have an idea of what that plugin does, not even what it's name is.
Now, it should behave like a static property, but static is not overridable so it seems that I cannot declare it as a part of an interface nor in an abstract class. Maybe I'm on wrong way, and it only looks like a static property and I can achive this functionality through another approach. So the brief question might be "How to enforce the third party developer to provide some meta information about his plugin". Please advise.
You could try with two interfaces:
IAddIn for be the main interface that all add-ins will implement.
IAddInInfo for be the interface providing the metadata of the add-in (name, publisher, description version etc.)
Each add-in should implement both of these. An IAddInInfo implementation could be like this:
public class ScannerAddInInfo : IAddInInfo
{
public string Name { get { return "Scanner"; } }
public string Description { get { return "Add-in for acquiring images from a scanner device"; } }
}
To ensure that all implementations of add-ins come with metadata, you can make IAddIn a generic interface like:
public interface IAddIn<T> where T : IAddInInfo
{
T Info { get; }
//Continue with the rest of the members you would want every add-in to have.
}
Then the scanner add-in implementation would be:
public class ScannAddIn : IAddIn<ScannerAddInInfo>
{
private ScannerAddInInfo _info = new ScannerAddInInfo();
public ScannerAddInInfo Info { get { return _info; } }
//Continue with the rest of the IAddIn implementation.
}
Then you could load the add-in assembly from a special add-in folder and create instances of the types implementing IAddInInfo and show the info from the discovered add-ins in your application. Note that no add-ins are created yet. To do so you will need to add some more reflection to find the types implementing IAddIn<ScannerAddInInfo>.
To make this simpler you could add the add-in type name to the IAddInInfo interface or something like that.
The only drawback to this approach is that you will have to load all assemblies found in your special add-in folder even if they do not include any add-ins.
To avoid this you could try Mono.Cecil. You then will have to do something like this:
AssemblyDefinition ad = AssemblyDefinition.ReadAssembly(assemblyPath);
foreach (TypeDefinition td in ad.MainModule.GetTypes())
{
if (td.BaseType != null && td.BaseType.FullName == "MyNamespace.MyAddInBase")
{
return true;
}
}
To load the assemblies you can use Assembly.LoadForm and to create instances of the add-ins and add-in infos, one of the Activator.CreateInstance overloads.
Good luck.
To add some 'meta data' to your plugins, you can use attributes. Create a custom attribute for your plugins and read out the information with reflection and show it in your application.
More info about attributes:
Creating Custom Attributes (C# and Visual Basic)
Accessing Attributes by Using Reflection
The thing you should do is basically define your interface and expect other people to implement their concrete classes and give that runtime object to you somehow (your predefined methods, configuration etc.)
But there is some mechanism called dependency injection. That allows you to define your interface and your entry points while a "system" takes care of matchmaking your entry points and implementers' concretes. There is "System.ComponentModel.Composition" namespace for this purpose.
I knew there was a framework called "Unity" doing such job. I guess composition namespace is somewhat a simplified version of unity. You can check help for "ImportAttribute" and "ExportAttribute" classes for some cue.
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.