C# 2.0 Why stop at partial interfaces?
-
Does anyone here plan on using the new "partial" keyword for their own C# class libraries? Seems like it was a plug for the Visual Studio Designer and it made its way to partial interfaces and structs as well :sigh: Jim
-
Does anyone here plan on using the new "partial" keyword for their own C# class libraries? Seems like it was a plug for the Visual Studio Designer and it made its way to partial interfaces and structs as well :sigh: Jim
Jim Bennett wrote:
Does anyone here plan on using the new "partial" keyword for their own C# class libraries?
So that your library can be extended by a user ? I'd expect not, surely ? Christian Graus - Microsoft MVP - C++
-
Jim Bennett wrote:
Does anyone here plan on using the new "partial" keyword for their own C# class libraries?
So that your library can be extended by a user ? I'd expect not, surely ? Christian Graus - Microsoft MVP - C++
I like my users, so I would never throw partial types at them :-D Jim
-
Does anyone here plan on using the new "partial" keyword for their own C# class libraries? Seems like it was a plug for the Visual Studio Designer and it made its way to partial interfaces and structs as well :sigh: Jim
Jim Bennett wrote:
Does anyone here plan on using the new "partial" keyword for their own C# class libraries?
I'm a big fan of using private classes for delegating class responsibilities. I used these a lot in my C++ days but shyed away from them in C# because the private class had to share the same source file as its parent class. So while I still used them when appropriate, I felt I was adding to a source file's code bloat, so I would look for other solutions, such as making a helper class internal. With the partial feature, I'll probably return to using them more often and relying less on the internal feature as a way of factoring out class functionality that should remain private to a class. Also, the partial feature will make home grown code generation easier, in my opinion. You factor out the code generated parts of a class to its own source file using the partial feature. If you need to regenerate the code, you don't have to worry about stepping on the hand coded parts of the class. Just regenerate the source file with the code generated parts, and you're on your way. So yeah, I'll probably use the partial feature. :)
-
Jim Bennett wrote:
Does anyone here plan on using the new "partial" keyword for their own C# class libraries?
I'm a big fan of using private classes for delegating class responsibilities. I used these a lot in my C++ days but shyed away from them in C# because the private class had to share the same source file as its parent class. So while I still used them when appropriate, I felt I was adding to a source file's code bloat, so I would look for other solutions, such as making a helper class internal. With the partial feature, I'll probably return to using them more often and relying less on the internal feature as a way of factoring out class functionality that should remain private to a class. Also, the partial feature will make home grown code generation easier, in my opinion. You factor out the code generated parts of a class to its own source file using the partial feature. If you need to regenerate the code, you don't have to worry about stepping on the hand coded parts of the class. Just regenerate the source file with the code generated parts, and you're on your way. So yeah, I'll probably use the partial feature. :)
I see your point on using partial classes to hide the private class implementation from the public section so you can move away from private classes. And yes, generated code should be hidden from view at all times too:) Jim
-
Does anyone here plan on using the new "partial" keyword for their own C# class libraries? Seems like it was a plug for the Visual Studio Designer and it made its way to partial interfaces and structs as well :sigh: Jim
I originally thought I'd be using them to keep file sizes managable, but I've gone off the idea. If a class is that big that it needs to be split into several files, then it probably needs to be split into several classes as well. cheers Chris Maunder
-
I originally thought I'd be using them to keep file sizes managable, but I've gone off the idea. If a class is that big that it needs to be split into several files, then it probably needs to be split into several classes as well. cheers Chris Maunder
Yeah, I agree. The best use IMO is to keep the auto generated stuff out of our faces. Christian Graus - Microsoft MVP - C++
-
I originally thought I'd be using them to keep file sizes managable, but I've gone off the idea. If a class is that big that it needs to be split into several files, then it probably needs to be split into several classes as well. cheers Chris Maunder
Chris Maunder wrote:
I originally thought I'd be using them to keep file sizes managable, but I've gone off the idea. If a class is that big that it needs to be split into several files, then it probably needs to be split into several classes as well.
I kind of agree with this, but I wonder... Say you have a class that has a well-defined set of responsibilities. It implements several interfaces, for example,
IComponent,IDisposable(included withIComponent), andISynchronizeInvoke. Each one of these interfaces is pretty small by themselves, but together they add up to a fair number of properties and methods. Then you have the class's own fields, events, properties, constructors, methods, and even a class that is nicely grained in the context of a library takes a pretty good chunk of source code to implement. With such a class, it's not always obvious how to factor out parts of it into classes. So maybe the partial feature would be nice way to factor out each interface implementation into its own source file. This would seem to be a good division point. Currently, we use Visual Studio to segragate each interface implementation with regions, so why not go a step further with the partial feature? It might make the size of source files more managable. This could be taken to an extreme and abused, of course, but if used wisely, it might be something to consider. Many classes are pretty simple, while others are more like components in that they offer a comprehensive set of services. Components can be made up of other classes, many times private (see my earlier post to this thread), and often implement several interfaces. I think these types of classes that represent larger building blocks within an application or library are key candidates for the partial feature. At least I look forward to taking that approach. After gaining some insight from actually using the feature, I may change my mind about it or have a different take. We'll see. -
Yeah, I agree. The best use IMO is to keep the auto generated stuff out of our faces. Christian Graus - Microsoft MVP - C++
Ive got the same impression , that you should use partial for splitting user code from autogen code. so that one file can be regenerated and the other is still intact. and maybe maybe to separate some interface implementations from the rest of the code
-
Chris Maunder wrote:
I originally thought I'd be using them to keep file sizes managable, but I've gone off the idea. If a class is that big that it needs to be split into several files, then it probably needs to be split into several classes as well.
I kind of agree with this, but I wonder... Say you have a class that has a well-defined set of responsibilities. It implements several interfaces, for example,
IComponent,IDisposable(included withIComponent), andISynchronizeInvoke. Each one of these interfaces is pretty small by themselves, but together they add up to a fair number of properties and methods. Then you have the class's own fields, events, properties, constructors, methods, and even a class that is nicely grained in the context of a library takes a pretty good chunk of source code to implement. With such a class, it's not always obvious how to factor out parts of it into classes. So maybe the partial feature would be nice way to factor out each interface implementation into its own source file. This would seem to be a good division point. Currently, we use Visual Studio to segragate each interface implementation with regions, so why not go a step further with the partial feature? It might make the size of source files more managable. This could be taken to an extreme and abused, of course, but if used wisely, it might be something to consider. Many classes are pretty simple, while others are more like components in that they offer a comprehensive set of services. Components can be made up of other classes, many times private (see my earlier post to this thread), and often implement several interfaces. I think these types of classes that represent larger building blocks within an application or library are key candidates for the partial feature. At least I look forward to taking that approach. After gaining some insight from actually using the feature, I may change my mind about it or have a different take. We'll see.Leslie Sanford wrote:
it's not always obvious how to factor out parts of it into classes. So maybe the partial feature would be nice way to factor out each interface implementation into its own source file.
You could also say that whenever you face this choice of division with interface implementations you could make a run at creating new classes (rather than use the partial class technique) and see how it works out with those classes:) Jim
-
I originally thought I'd be using them to keep file sizes managable, but I've gone off the idea. If a class is that big that it needs to be split into several files, then it probably needs to be split into several classes as well. cheers Chris Maunder
Hey Chris, Well said! Jim