¿Por qué usar clases parciales?

En mi opinión, la partialpalabra clave no hace más que permitir que una clase se divida entre varios archivos de origen. ¿Hay alguna razón para hacer esto que no sea para la organización del código? Lo he visto usado para eso en las clases de IU generadas.

Parece una mala razón para crear una palabra clave completa. Si una clase es lo suficientemente grande como para requerir múltiples archivos, probablemente esté haciendo demasiado. Pensé que tal vez podría usarlo para definir parcialmente una clase para que otro programador la complete, pero sería mejor hacer una clase abstracta.

Es muy útil en todos los escenarios en los que una herramienta personalizada genera una parte de la clase porque le permite agregar lógica personalizada al código generado sin heredar la clase generada. Por cierto. También hay métodos parciales por la misma razón.

No se trata solo de la interfaz de usuario, sino también de otras tecnologías como Linq-To-Sql o Entity Framework que lo utilizan bastante.

Como usted dice, a menudo se usa para separar el código generado. A menudo no tiene nada que ver con el tamaño de las clases / archivos.

El beneficio de separar el código generado es uno de estilo. El código generado puede ser bastante feo e ilegible y fallaría en muchos estándares de codificación (y comprobaciones de StyleCop), pero está bien, nadie tiene que leerlo o mantenerlo directamente. Entonces, si lo "oculta" en otro archivo, puede enfocarse en asegurarse de que el resto de la clase esté a la altura, pase las comprobaciones de StyleCop, etc.

Otra área donde la he usado es donde una clase implementa múltiples interfaces, puede ser bastante agradable separar la implementación en archivos separados, aunque esto es más una cuestión de preferencia personal, nunca he visto que requieran estándares de codificación ( o prevenir) esto.

Hace un par de semanas, uno de los desarrolladores en los que trabajo tuvo un uso bastante bueno para ellos en la refactorización de grandes clases de Dios que se han salido de control y tienen muchos métodos públicos: separando las funciones lógicas de cada bit de la clase en clases parciales separadas puede separar físicamente la clase en las unidades más atómicas que deberían ser las clases sin romper ninguna funcionalidad existente, lo que le permite ver qué es común y qué no. Con esto como una primera etapa, puede dividir más fácilmente los parciales en sus propias clases independientes e implementarlos en toda la base de código. Pensé que era una buena idea.

Sin embargo, en general creo que solo deberían usarse para aumentar las clases generadas por la máquina al escribir código nuevo.

Puedo pensar en algunos escenarios útiles en los que los parciales tienen sentido, la mayoría de ellos los estoy usando en mis proyectos:

• Para separar el código generado por Tool / IDE / Designer del código que está manteniendo. Un buen ejemplo es el Form.Designer.csarchivo que contiene el código generado por el diseñador para las aplicaciones de formularios de Windows. Muchos otros formatos .NET también tienen código generado por herramientas, que puede regenerarse potencialmente cuando construye su proyecto, y por lo tanto, todos sus cambios personalizados se eliminarán. La separación lo ayudará a mantener su código y los cambios a salvo de tales modificaciones automáticas.

• Cuando implementa múltiples interfaces con mucho código en la implementación. Yo tiendo a usar un archivo parcial por separado para cada interfaz, dándole el nombre de esta manera: {Class}.{Interface}.cs. Es fácil para mí ver en el IDE qué interfaces {Class}está implementando y cómo.

• Cuando la clase debe contener una o más clases anidadas , especialmente con suficiente código para colocarlas en un archivo separado. Me apegaría al patrón anterior y usaría la {Class}.{NestedClass}.csconvención de nomenclatura para cada clase anidada. Práctica similar ya se menciona en la respuesta de Virtlink .

• Cuando escribo staticclases que contendrán métodos de extensión . A menudo será el caso proporcionar la misma lógica de método de extensión a clases o interfaces similares, como por ejemplo Reverseen colecciones genéricas y no genéricas. Pondría todos los métodos de extensión para una sola clase o interfaz en un parcial separado de la clase estática. Por ejemplo, tendría todos los métodos de extensión para la IListinterfaz en un lugar, y los mismos métodos para IList<T>otro archivo. Otro enfoque sería colocar el mismo método (todas sus sobrecargas) en el mismo parcial, con todas las clases posibles para el thisparámetro, como tener todas lasReverseimplementaciones en un archivo. Depende de cuál justificaría mejor la separación en términos de volumen de código, o algunas convenciones internas a las que usted o su organización podrían estar apegándose.

• No uso esto, pero he visto a algunas personas de C / C ++ que les gusta el enfoque que describiré aquí: crear un parcial para la clase solo con métodos parciales . Esto se parece a la forma C / C ++ de definir interfaces y separar la declaración del método de la implementación.

• Separación por preocupaciones puramente lógicas . Si trabaja con una clase grande que combina más de un conjunto lógico de operaciones en sí mismo, entonces podría separar cada código lógicamente relacionado en un parcial separado. Por lo general, la existencia de tales clases está en contra del principio de separación de preocupaciones , pero a menudo se observa el caso de la vida real, especialmente para las bases de código más antiguas. El usuario Steve Evers los ha mencionado en su respuesta a esta pregunta , refiriéndose a ellos por el nombre de objetos de dios. Yo personalmente usaría el enfoque de clases parciales para dividir el código antes de que tenga lugar una refactorización de archivos tan grandes, para facilitar mi trabajo y hacer que la refactorización sea más transparente. Esto también reducirá los conflictos que potencialmente causaré cuando estén involucrados sistemas de versiones como SVN.

No lo he visto mencionado por nadie: lo uso partialpara poner clases anidadas en sus propios archivos.

Todos mis archivos de código contienen solo una clase, estructura, interfaz o enumeración. Hace que sea mucho más fácil encontrar la definición de un objeto cuando los nombres de los archivos muestran el nombre de lo que está buscando. Y dado que Visual Studio intenta hacer coincidir las carpetas del proyecto con los espacios de nombres, los nombres de los archivos deben coincidir con las clases.

Esto también significa que una clase NestedClassanidada dentro MyClasstendrá su propio archivo en mis proyectos: MyClass.NestedClass.cs.

partial class MyClass
{
    private class NestedClass
    {
        // ...
    }
}

Con la excepción del uso de código generado, solo los he visto usar en un esfuerzo por encubrir objetos de Dios . Intentar comprender una nueva base de código o navegar a través de múltiples archivos fuente, que son el mismo objeto, es muy molesto.

Entonces, cuando preguntas Why use partial classes?, respondo: a menos que estés usando el código generado, no lo hagas.

La organización del código es la única razón, pero es más profunda de lo que parece a primera vista. Si tiene clases parciales donde se generan partes, puede fácilmente:

• Regenere el código sin tener que detectar cambios manuales en las clases en las que escribe (para no sobrescribir esas partes).
• Excluya las clases parciales generadas de la cobertura de prueba, control de fuente, métricas, etc.
• Use el código generado sin obligarlo a basar su estrategia de herencia en torno a él (aún puede heredar de otras clases).

También hay algunos lugares donde las clases generadas / implícitas se declaran parciales, por lo que si el desarrollador necesita extenderlas, tienen acceso completo sin tener que preocuparse por heredar y anular todo el lugar. Observe las clases generadas en el área temporal asp.net después de ejecutar un sitio de formularios web por primera vez en IIS si desea obtener algunos ejemplos.

Puedo pensar en un uso sucio para ellos.

Suponga que tiene algunas clases que necesitan una funcionalidad común, pero no desea inyectar esa funcionalidad en la cadena de herencia que se encuentra sobre ellas. O bien, tiene un conjunto de clases que utilizan una clase auxiliar común.

Básicamente, desea hacer herencia múltiple, pero C # no es similar. Entonces, lo que haces es usar parcial para crear lo que es esencialmente un #include en C / C ++;

Ponga toda la funcionalidad en una clase, o use la clase auxiliar. Luego copie el ayudante X veces y cámbiele el nombre a la clase parcial A, B, C. y poner parcial en sus clases A, B, C.

Descargo de responsabilidad: Sí, esto es malo. No lo hagas nunca, especialmente si enfadará a otras personas contigo.