definicion - sealed class c#
Clases parciales en C# (20)
¿Hay buenos usos de las clases parciales fuera de los escenarios de códigos generados por webforms / winforms? ¿O es esta característica básicamente para apoyar eso?
A menudo uso clases parciales para dar a cada clase anidada su propio archivo. Hubo algunas arquitecturas en las que trabajé, donde la mayoría de la implementación solo era requerida por una clase y entonces anidamos esas clases en esa clase. Tenía sentido mantener los archivos más fáciles de mantener utilizando la capacidad de clase parcial y dividiendo cada uno en su propio archivo.
También los hemos utilizado para agrupar anulaciones de existencias o para ocultar un conjunto de propiedades. Ese tipo de cosas. Es una forma práctica de mezclar en un cambio de stock (simplemente copie el archivo y cambie el nombre de la clase parcial a la clase objetivo, siempre y cuando la clase objetivo también se haga parcial, por supuesto).
A veces puede encontrar un código terriblemente viejo en el trabajo que puede hacer casi imposible refactorizar en elementos distintos sin romper el código existente.
Cuando no se le da la opción o el tiempo para crear una arquitectura más genuina, las clases parciales hacen que sea increíblemente fácil separar la lógica donde sea necesaria. Esto permite que el código existente continúe usando la misma arquitectura mientras que usted gana un paso más cerca de una arquitectura más concreta.
Acabo de encontrar un uso para clases parciales. Tengo una clase [DataContract] que uso para pasar datos al cliente. Quería que el cliente pudiera mostrar la clase de una manera específica (salida de texto). así que creé una clase parcial y anulé el método ToString.
Como mencioné anteriormente, yo también creo que esto es un olor a código.
Si una clase es tan grande que debe dividirse en más archivos, significa que está rompiendo el principio de responsabilidad única y haciendo demasiadas cosas. La clase grande podría dividirse en clases más pequeñas que cooperen juntas.
Si tiene que usar clases o regiones parciales para organizar el código, considere si deberían estar en sus propias clases. Aumenta la legibilidad y obtendrías más reutilización de código.
Corrección, como señaló Matt, ambos lados del parcial deben estar en la misma asamblea. mi error.
EDITAR: DSL Tools for Visual Studio usa clases parciales.
Por lo tanto, es una característica que utilizan muchos códigos generados automáticamente. En lugar de usar #region, el código generado automáticamente va a un archivo y el código de usuario (también llamado código personalizado) va a otro e incluso en diferentes directorios para que el desarrollador no se confunda con tantos archivos sin sentido.
Es bueno tener esta opción que puedes combinar, pero no forzar, con herencia
Además, puede ser útil separar la lógica de algunas clases entre varios directorios. Por supuesto, para las máquinas, es lo mismo, pero mejora la experiencia de legibilidad del usuario.
En UserControls, que son relativamente complicados, pongo el material de manejo de eventos en un archivo y la pintura y las propiedades en otro archivo. Las clases parciales funcionan muy bien para esto, por lo general, estas partes de la clase son relativamente independientes y es agradable poder editar pintura y manejo de eventos uno al lado del otro.
En cualquier lugar donde haya usado secciones #region probablemente tenga más sentido como archivos separados en clases parciales.
Yo personalmente uso clases parciales para clases grandes donde los miembros estáticos van en un archivo y los miembros de la instancia van en el otro.
En donde estoy, tenemos un programa que maneja los archivos entrantes de los clientes. Está configurado para que el código de cada cliente esté en su propio proyecto de biblioteca de clase, que sabe cómo manejar cualquier formato que el cliente decida usar.
El código principal utiliza las bibliotecas definiendo una interfaz bastante extensa que debe implementar una clase en la biblioteca (probablemente debería haber algunas interfaces distintas, pero es demasiado tarde para cambiarla ahora). A veces eso implica mucho más código en la misma clase de lo que normalmente consideramos prudente. Las clases parciales nos permiten dividirlas un poco.
En general, lo considero un olor a código.
Si su clase es tan complicada, probablemente se pueda dividir en componentes reutilizables más pequeños.
O significa que no hay jerarquía de herencia donde debería haber una.
Para los escenarios de generación de código es bueno, pero creo que la generación de código es otro olor a código.
En parte, es compatible con los escenarios (WebForms, WinForms, LINQ-to-SQL, etc.) que mezclan el código generado con el código del programador.
Hay más razones para usarlo. Por ejemplo, si tiene grandes clases en archivos grandes y poco manejables, pero las clases tienen grupos de métodos lógicamente relacionados, las clases parciales pueden ser una opción para hacer que los tamaños de sus archivos sean más manejables.
Encuentro que las clases parciales son extremadamente útiles. Por lo general, se utilizan para poder extender clases autogeneradas. Los usé en un proyecto con pruebas de unidades pesadas. Mis clases de UT tenían dependencias complejas y no era muy práctico separar el código entre varias clases. Por supuesto, es mejor usar la herencia / composición, pero en algunos casos las clases parciales pueden ser útiles.
LINQ to SQL hace un buen uso de las clases parciales para extender el código generado por el diseñador. Creo que normalmente encontrará este patrón de clases parciales que utiliza el código creado por el diseñador.
La generación de código fue la fuerza impulsora detrás de las clases parciales. La necesidad proviene de tener una clase generada por código que cambia constantemente, pero permite a los desarrolladores proporcionar código personalizado como parte de la clase que no se anulará cada vez que se realicen cambios que obliguen a la clase a regenerarse.
Tome WinForms o Typed-DataSets por ejemplo (o cualquier diseñador para el caso). Cada vez que realiza un cambio en el diseñador, serializa el código correspondiente en un archivo. Supongamos que debe proporcionar algunos métodos adicionales que el generador no conoce. Si lo agregó al archivo generado, sus cambios se perderían la próxima vez que se generara.
Un proyecto en el que estoy trabajando actualmente usa la generación de código para todas las entidades DAL, BLL y comerciales. Sin embargo, el generador solo nos obtiene el 75% de la información. La porción restante tiene que estar codificada a mano (lógica de negocios personalizada, por ejemplo). Puedo suponer que cada clase BLL tiene un método SelectAll, por lo que es fácil de generar. Sin embargo, mi cliente BLL también necesita tener un método SelectAllByLocation. No puedo poner esto en mi generador porque no es genérico para todas las clases BLL. Por lo tanto, genero todas mis clases como clases parciales, y luego en un archivo separado defino mis métodos personalizados. Ahora, cuando mi estructura cambie, o si necesito regenerar mi BLL por alguna razón, mi código personalizado no se borrará.
Lo uso en una capa de acceso a datos. Las clases generadas como el asignador y las consultas son parciales. Si necesito agregar un método mapper, por ejemplo, para hacer una carga de fantasía que no se genera, la agrego a la clase personalizada.
Al final, el programador que usa la capa de datos en la capa de negocios solo ve una clase con toda la funcionalidad que necesita. Y si la fuente de datos cambia, las partes genéricas se pueden generar fácilmente sin sobrescribir las cosas personalizadas.
Trabajé en un proyecto hace un par de años donde teníamos una clase DataSet tipeada que contenía un montón de código: métodos en DataTables, métodos en TableAdapters, declaraciones de instancias de TableAdapter, lo que sea. Era un punto central masivo del proyecto en el que todos tenían que trabajar a menudo, y había mucha contención de control de fuente sobre el archivo de código de clase parcial.
Así que dividí el archivo de código en arreglo o seis archivos de clase parciales, agrupados por función, para poder trabajar en piezas más pequeñas y no tener que bloquear todo el archivo cada vez que teníamos que cambiar algo pequeño.
(Por supuesto, también podríamos haber resuelto el problema al no usar un sistema de control de fuente de bloqueo exclusivo, pero ese es otro problema).
Utilizo clases parciales como medio para separar los diferentes elementos secundarios de los controles personalizados que escribo. Además, cuando se utiliza con el software de creación de entidades, permite que productos como LLBLGen creen versiones de clases generadas, así como una versión personalizada editada por el usuario, que no será reemplazada si las entidades necesitan ser regeneradas.
Otro posible uso de las clases parciales sería aprovechar los métodos parciales para hacer que los métodos desaparezcan selectivamente mediante la compilación condicional; esto sería ideal para el código de diagnóstico de modo de depuración o escenarios de pruebas de unidades especializadas.
Puede declarar un método parcial como un método abstracto, luego en la otra clase parcial, cuando escribe la palabra clave "parcial" puede aprovechar el Intellisense para crear la implementación de ese método.
Si rodea una parte con sentencias de compilación condicionales, puede cortar fácilmente el código de depuración o de prueba. En el ejemplo siguiente, en el modo DEBUG, se llama al método LogSomethingDebugOnly, pero en la compilación de lanzamiento, es como si el método no existiera en absoluto: una buena forma de mantener el código de diagnóstico alejado del código de producción sin un montón de ramificaciones o múltiples bloques de compilación condicional.
// Main Part
public partial class Class1
{
private partial void LogSomethingDebugOnly();
public void SomeMethod()
{
LogSomethingDebugOnly();
// do the real work
}
}
// Debug Part - probably in a different file
public partial class Class1
{
#if DEBUG
private partial void LogSomethingDebugOnly()
{
// Do the logging or diagnostic work
}
#endif
}
Estoy tarde en el juego ... pero solo mis 2 centavos ...
Un uso podría ser refactorizar una clase div existente en una base de código heredada existente para múltiples clases parciales. Podría mejorar la capacidad de detección del código, si se siguen las convenciones de nomenclatura adecuadas para los nombres de archivo que contienen las clases parciales. Esto también podría reducir el repositorio de código fuente: resolver y fusionar hasta cierto punto.
Idealmente, una clase divina debería dividirse en múltiples clases pequeñas, cada una con una responsabilidad única. A veces es perjudicial realizar refactorizaciones medianas a grandes. En tales casos, las clases parciales podrían proporcionar un alivio temporal.
tal vez sea demasiado tarde, pero por favor permítanme agregar mis 2 centavos también:
*. Al trabajar en proyectos grandes, distribuir una clase en archivos separados permite que varios programadores trabajen en él simultáneamente.
*. Puede escribir fácilmente su código (para funcionalidad extendida) para una clase generada VS.NET. Esto le permitirá escribir el código de su propia necesidad sin interferir con el código generado por el sistema