In a C# project, I need to add many classes that each have 10 common properties, each one adding several specific properties.
It is expected that the number of common properties will grow up to 20.
I would like to:
Have a base class / file that would hold all the common properties
Create those many classes without inheriting the base class and the new classes have the common properties from the base class/file.
In the "derived" classes I can add new properties.
In the future, when the list of common properties will grow, I would just edit the base class/file and have them inserted automatically in all "descendant" classes.
Basically, I need a placeholder inserted somewhow in my files that links to an external file and add the content into the classes at compile time, just as #include directive works in C++.
So I need inheritance without deriving the classes, it that makes sense.
Probably the closet you can get is interface properties. You will still need to implement the properties in the "descendant" classes. It would be fairly easy to write a script yourself that implements them as auto-properties when the master file changes though.
You can easily generate your classes with CodeDOM. See that example.
You can use a compilation-time T4 text template. There you can add all your properties and from there the code is multiplied and you can even change it as you like. If you need individual code for these classes, you can just make the classes partial and add the individual code in manual files.
BUT: You will hardly get any IDE features for T4. There are some extensions that at kleast give you some syntax highlighting, but basically thats it.
Related
My program has a ReportConfiguration class that is used to store configuration information for the report. Logically, there are many areas that need to be configured, namely in how certain types of sections are displayed etc. A friend suggested that I take these sections and make them nested classes, such that:
public abstract class ReportConfiguration{
private class AssessmentTypeConfiguration{
}
}
public class MyConfiguration : ReportConfigration{}
Essentially, while I am going to be using these, I will be exposing these configuration classes to other developers who may want to extend some functionality, or write some tools that require the configuration to be modified. So I want them to be able to extend the configuration class, but there may be certain configuration options I do not want them to touch, or that just logically seem as if they should be nested.
The question: Is it even necessary to use separate classes, or just make one very large class with lots of properties for every configuration option?
I would recommend doing separate classes rather than one giant class for a few reasons:
It helps to group like information together so that it's easier to reason about
If you want to serialize and/or read the information they contain from a configuration file (or files), it'll be easier and probably more flexible to do so with smaller classes
If you're going with non-static classes (or ever want to), and are going to pass instances around, it makes more sense to pass limited information around rather than a giant object with everything under the sun
You say there are clearly separated configuration areas, so you should have clearly separated classes to match that. Otherwise, your single class might know too much, and classes should only be responsible for one thing.
With C++, I can have one class definition in a header file, and have a multiple implementation files by including the header file.
With C#, it seems that there is no such header file, as one class should contain both definition/implementation.
I wonder if the number of lines can be very big, because one can't separate the class into multiple files. Am I correct? I mean, in some cases, one can't change the class design to have smaller classes. In this case, is there a way to solve this problem?
You can separate a class into multiple files using the partial keyword
public partial class ClassNameHere
{
}
It is possible to split the definition of a class or a struct, or an interface over two or more source files using the Partial keyword modifier Link to msdn with the partial class
Partial classes only give you so much. There is still no way, that i know of, to split your class definition from implementation, such that each exists in a separate file. So if you like to develop based on a need-to-know paradigm then you are sort of stuck. Basically there are three levels a developer can work at...
1) Owns all the code and has access to, and maintains all of it.
2) Wishes to use some useful base class(s) which may form part of a framework, or may just be a useful class with some virtual methods, etc, and wishes to extend, or re-implement some virtual base class methods of interest. Now the developer should not need to go and look at the code in the base class(s) in order to understand things at a functional level. If you understand the job of a function, it's input and output parameters, there is no need to go and scratch inside source code. If you think there's a bug, or an optimization is needed, then refer to the developer from 1) who owns and maintains the base code. Of course there's nothing saying that 1) and 2) cannot be associated with the same developer, in which case we have no problem. In fact, this is more than often the case i suspect. Nevertheless, it is still good practice to keep things well separated according to the level at which you are working.
3) A developer needs to use an already packaged / sealed object / component dll, which exposes the relevant interfaces.
Within the context of c#, 1) and 3) have no problems. With 2) i believe there is no way to get round this (unless you change from exposing virtual base methods to exposing interface methods which can be reimplemented in a component owning the would-be base class). If i want to have a look at a class definition to browse over the methods, scaffolding functions, etc, i have to look at a whole lot of source code as well, which just gets in the way of what i am trying to focus on.
Of course if there is class definition documentation external to how we normally do it ( in headers and source files), then i must admit, that within the context of 2), there is not reason to ever look into a class definition file to gain functional knowledge.
So maybe clever Tom's came up with c#, decided to mix class definition with implementation in an attempt to encourage developers to have external documents for their class definitions, and interfaces, which in most IT companies is severely lacking.
Use a partial class as #sparks suggests, or, split into several classes. It's a good rule of thumb that, if you can't fit a class onto a couple of pages, it's complicated enough to need breaking apart.
Is it possible to have two parts (same namespace, same class name) to a partial class in separate DLLs?
From MSDN -Partial Classes and Methods:
All partial-type definitions meant to
be parts of the same type must be
defined in the same assembly and the
same module (.exe or .dll file).
Partial definitions cannot span
multiple modules.
No. Partial classes are a purely language feature. When an assembly is compiled, the files are combined to create the type. It isn't possible to spread the files out into different assemblies.
Depending on what you want to do, though, you might be able to use extension methods to accomplish what you need.
No it is not possible. When the assembly is compiled the class needs to be finished.
While other answers do provide the unpleasant "No" that anyone landing on this page didn't want to see, I was struck by another thought that hasn't been mentioned here yet. If partial classes were allowed across assemblies, one would get access to private members of existing types that were not written by him, thus allowing him to manipulate them in ways that were not intended by the original author, thus jeopardizing the functionality of all inheriting classes too.
Not only that, those classes in other assemblies (and their children) would need to be recompiled to make it work. Thus it is logically not possible to allow splitting a class over different assemblies.
Note: Read #Zar Shardan's comment below. That is another very important issue, even more important than private member access.
You can use extension methods when you want to add a method to a class in a different dll.
The one drawback of this method is that you cant add static methods.
The question is why would you want to make a partial class in another assembly? You can define abstract classes and interfaces across assemblies, maybe you need to look into that.
You probably just want to create a Wrapper class within you own library, around the class in the 3rd part library. Then add whatever functionality to the wrapper class.
The problem I'm having is, using the POCO templates, generating my POCO classes the first time only and not overwriting them when the templates are re-ran. I know this sounds hokey and the reason is that I'm actually changing these templates and trying to generate metadata classes rather than the actual POCO classes, but these metadata classes will be hand-edited and I want to keep those edits in the future but still regenerate a certain amount of it. I have it all working exactly as I want except for the regeneration of the files.
I have looked into T4 and it seems that there is a flag to do just this (see the Output.PreserveExistingFile property) but I don't understand where/how to set this flag. If you can tell me where/how to set this in the default POCO templates, then I think that's all I really need.
Thanks!! :-)
PreserveExistingFile property is only available in T4 Toolbox. POCO templates are plain T4, someone would have to convert them. Any volunteers?
You're doing this wrong.
All the classes created are partial classes. If you wish to alter the templates create new partial classes and put your code in them.
I know it lets visual studio to separate WinForms UI code from the UI events, etc. But are there any practical uses for it?
The partial keyword is typically used in code generation utilities to allow developers to add additional functionality to the generated code without the fear of that code being erased if the code is generated again.
With C# 3 the partial keyword can be applied to methods to allow users of generated code to fill in blanks left by the generator. The Linq To Sql designer for example provides partial methods that allow you to add logic to the classes that the framework will call if implemented. The benefit here is that the C# compiler will completely remove unimplemented partial methods, so there is no performance hit at all for not implementing them.
Partial classes can also be used to organize very large classes into separate code files, although this sort of usage is usually a sign that your classes are too large and are taking on too many responsibilities.
The best use for the partial keyword that I can think of is nested classes. Without the partial keyword all nested classes must go in the same code file as the containing class.
One use I have found is for code that you may not want to exist in production code such as tracing or dev logging code. You could place this in the partial class and then when you do a production build you simply build without those partials included and the compiler will auto-magically strip out any calls to those partials that were excluded.
I'm using it for partitioning helper classes where some methods need lots of code. This is quite an easy way of retaining readability as each file only deals with a portion of the class's functionality.
In VB you can use it to separate "normal" code from code that needs late binding via "Option Strict Off".
In C# I only use it for unusually large classes.
The LINQ to SQL designer uses it extensively to split custom behaviors (partial methods) outside of the mapping class.
In short, its main purpose is for code generators.
Hope this helps.
I use partial classes and methods all the time with Linq2Sql. Otherwise I have never used it for anything besides UI/Code-behind classes.
One of the great things that I like about partial classes in linq2sql is that you can have the partial class inherit an interface and it will map the interface to the generated class. This is great if you have more than one Data provider and still want to use the same interfaces for all the Data access classes.
WPF uses partial classes extensively. The XAML generates a partial class that you can add to.
I use partial classes to reduce the merge pain with version control when I know that we would have several developers working on one class. For example, we often have our DAL class split into several partial class files. If you don't put them in different files, it's easy to get merge conflicts that take a while to fix when checked into version ctl.
When the develoment gets less chaotic as the class gets close to complete, we get rid of the partial files. We just use it to make VC/mulit-developer issues easier