c# design-patterns .net-3.5 partial-methods

¿Cómo se usan los métodos parciales en C#3.0?



design-patterns .net-3.5 (5)

Este es el mejor recurso para clases parciales en C # .NET 3.0: http://msdn.microsoft.com/en-us/library/wa80x488(VS.85).aspx

Intento evitar el uso de clases parciales (con la excepción de los parciales creados por Visual Studio para los archivos de diseñador; son geniales). Para mí, es más importante tener todo el código para una clase en un solo lugar. Si su clase está bien diseñada y representa una cosa ( principio de responsabilidad única ), entonces todo el código para esa cosa debe estar en un solo lugar.

He leído acerca de los métodos parciales en la última especificación del lenguaje C # , así que entiendo los principios, pero me pregunto cómo las personas realmente los están usando. ¿Hay un patrón de diseño particular que se beneficie de métodos parciales?


Los métodos parciales son muy similares en concepto al patrón de comportamiento del método de plantilla GoF ( Design Patterns , p325).

Permiten que el comportamiento de un algoritmo u operación se defina en un lugar e implemente o cambie en otro lugar, lo que permite la extensibilidad y la personalización. Empecé a usar métodos parciales en C # 3.0 en lugar de métodos de plantillas porque creo que el código es más limpio.

Una buena característica es que los métodos parciales no implementados no incurren en sobrecarga de tiempo de ejecución a medida que se compilan.


Los veo como eventos livianos. Puede tener un archivo de código reutilizable (generalmente autogenerado, pero no necesariamente) y para cada implementación, simplemente maneje los eventos que le interesan en su clase parcial. De hecho, así es como se usa en LINQ to SQL (y por qué se inventó la función de idioma).


La generación de código es una de las principales razones por las que existen y una de las principales razones para usarlas.

EDITAR: aunque ese enlace es información específica de Visual Basic, los mismos principios básicos son relevantes para C #.


Se han introducido métodos parciales por razones similares a por qué las clases parciales estaban en .Net 2.

Una clase parcial es aquella que se puede dividir en varios archivos: el compilador los compila en un solo archivo a medida que se ejecuta.

La ventaja de esto es que Visual Studio puede proporcionar un diseñador gráfico para una parte de la clase mientras que los codificadores funcionan para la otra.

El ejemplo más común es el diseñador de formularios. Los desarrolladores no quieren colocar botones, cuadros de entrada, etc. a mano la mayor parte del tiempo.

  • En .Net 1, era código generado automáticamente en un bloque #region
  • En .Net 2, estas se convirtieron en clases de diseñador separadas: la forma sigue siendo una clase, simplemente se divide en un archivo editado por los desarrolladores y otro por el diseñador de formularios.

Esto hace que mantener ambos sea mucho más fácil. Las fusiones son más simples y hay menos riesgo de que el diseñador de formularios VS deshaga accidentalmente los cambios manuales del programador.

En .Net 3.5 Linq ha sido presentado. Linq tiene un diseñador de DBML para construir sus estructuras de datos, y eso genera auto-código.

El bit adicional aquí es que el código es necesario para proporcionar los métodos que los desarrolladores pueden querer completar.

Como los desarrolladores ampliarán estas clases (con archivos parciales adicionales) no podrían usar métodos abstractos aquí.

El otro problema es que la mayoría de las veces no se llamará a estos métodos, y llamar a los métodos vacíos es una pérdida de tiempo.

Los métodos vacíos no están optimizados .

Entonces Linq genera métodos parciales vacíos. Si no creas tu propio parcial para completarlos, el compilador de C # simplemente los optimizará.

Para que pueda hacer esto, los métodos parciales siempre vuelven vacíos.

Si crea un nuevo archivo DBML de Linq, generará automáticamente una clase parcial, algo así como

[System.Data.Linq.Mapping.DatabaseAttribute(Name="MyDB")] public partial class MyDataContext : System.Data.Linq.DataContext { ... partial void OnCreated(); partial void InsertMyTable(MyTable instance); partial void UpdateMyTable(MyTable instance); partial void DeleteMyTable(MyTable instance); ...

Luego en su propio archivo parcial puede extender esto:

public partial class MyDataContext { partial void OnCreated() { //do something on data context creation } }

Si no amplías estos métodos, se optimizan al instante.

Los métodos parciales no pueden ser públicos, ya que tendrían que estar ahí para que otras clases puedan llamar. Si escribe sus propios generadores de código, puedo ver que son útiles, pero de lo contrario solo son realmente útiles para el diseñador de VS.

El ejemplo que mencioné antes es una posibilidad:

//this code will get optimised out if no body is implemented partial void DoSomethingIfCompFlag(); #if COMPILER_FLAG //this code won''t exist if the flag is off partial void DoSomethingIfCompFlag() { //your code } #endif

Otro uso potencial es si tuvo una clase grande y compleja derramada en varios archivos, es posible que desee referencias parciales en el archivo de llamadas. Sin embargo, creo que en ese caso debes considerar simplificar primero la clase.