Considere una clase que implementa muchas interfaces, ¿tendría sentido implementar cada interfaz en un archivo separado usando las definiciones partial class?Implementación de interfaces en clases parciales
¿Sería esto un abuso de la función de idioma o es un modismo que desconozco?
Si su clase tiene para implementar muchas interfaces, esa es una forma razonable de administrar la fuente, sí. Puede editar el archivo de proyecto para hacer que varios de ellos dependan de un archivo de clase "principal", lo que hace que el Explorador de soluciones sea más fácil de usar.
Debe preguntarse si no debería tener varias clases más pequeñas, cada una implementando una sola interfaz. Algunas veces ese será un mejor enfoque, otras no, pero siempre vale la pena hacer la pregunta.
Sí, de hecho, definitivamente vale la pena preguntar. –
Esa es una sugerencia interesante de cómo uno hace que los archivos fuente dependan el uno del otro? – Motti
@Motti: tiene que editar el archivo del proyecto a mano. Ver http://stackoverflow.com/q/223249/22656 para ver ejemplos. –
No es una expresión idiomática de la que haya oído hablar alguna vez, pero parece una forma elegante de particionar su código.
El único beneficio es tener las diversas implementaciones de interfaz en archivos físicos separados.
En mi opinión, esto se ve compensado por la desventaja de tener su declaración de clase ubicada en archivos físicos separados.
Puede, sí, pero eso no le dará más ventajas que, por ejemplo, un único archivo con regiones. Las clases parciales tienden a ser asquerosas porque no es inmediatamente obvio que haya otra parte en ellas, y alguien más que mire la clase podría perderla. Personalmente prefiero tener todo en un solo lugar.
Creo que debe preguntarse si tener un archivo .cs para cada interfaz implementada por su clase haría que sea más fácil o más difícil de entender el código. ¿Cómo nombrarías los archivos?
Aunque podría estar yendo por las ramas aquí, creo que voy a sugerir que use la muy odiada directiva #region en su lugar si la organización del código es su objetivo.
Pro: puede identificar fácilmente qué parte de una clase implementa qué interfaz (buena cuando se utiliza una herramienta que no permite navegar fácilmente a través del código dentro del IDE).
Contra: más fácil perder contexto, ya que ahora usted tiene que navegar a través de múltiples archivos
supone w/el avance en el IDE hoy en día, en realidad no importa. Puede tener un solo archivo y dejar que la herramienta lo ayude a navegar dentro de la estructura de su clase rápidamente. Pero, de nuevo, la herramienta puede ayudar de cualquier manera ... entonces ...
Parcial todavía es bueno para separar código generado vs código personalizado.
hace tanto sentido como que tienen los constructores en un archivo de clase parcial, propiedades en otro archivo de clase parcial, etc., etc.
es decir, No lo haga a menos que tenga una buena razón.
Creo que hay formas mejores de estructurar el código que usar parciales en este caso. No hay referencia en Visual Studio que pueda consultar para ver cuántas implementaciones parciales hay para una clase en particular, por lo que es fácil perder la pista.
Según la cantidad de interfaces que realmente quiere decir con "muchas interfaces", puede usar las regiones para separar las implementaciones. Eso estaría bien hasta 10-15 interfaces con un total de, digamos, 150 funciones para implementar. Después de eso, las cosas se pondrán complicadas y perderás una visión general. Y es allí donde se beneficiará de otros mecanismos, como la herencia, el encapsulado o la agregación, y el uso de servicios y clases de ayuda.
Pero me gustaría seriamente reconsiderar la arquitectura de su código si alguna vez se encuentra la necesidad de implementar interfaces de más de 15 ....
Una alternativa sencilla que utiliza Visual Studio por defecto es regiones. – CodesInChaos
No estoy seguro de si haría esto para las implementaciones de interfaz, pero lo he hecho antes para dividir varias clases anidadas privadas. –