2010-09-23 26 views
7

Cada vez me doy más cuenta de que mi código en cualquier archivo puede abarcar cientos de líneas con bastante facilidad y aunque sé que la implementación puede ser buena, todavía se siente desordenada y desorganizada.¿Cómo organizar grandes archivos de código?

Entiendo que hay situaciones en las que se necesita una gran cantidad de código, pero ¿cuál es la mejor manera de organizarlo todo?

He pensado en la separación de variables a partir de métodos, private s de s public y internals pero yo no quiero porque no puedo dejar de pensar que los componentes de una clase pertenecen en un solo archivo.

Todo esto se complica cuando estoy trabajando con el código detrás de una ventana de WPF, que siempre parece crecer a un ritmo exponencial en un gran lío muy rápidamente.

También: C# tiene una palabra clave llamada partial, que le permite dividir una clase en cualquier cantidad de archivos sin afectar la funcionalidad. Sin embargo, he notado que Microsoft solo parece usar partial para ocultar el código generado de usted (Winforms/WPF). Lo que me lleva a cuestionar si dividir una clase simplemente porque tiene muchas líneas es un uso legítimo de partial, ¿o sí?

Gracias

+3

Si puede dividir una clase en varios archivos 'parciales' que están lógicamente separados, en su lugar debería dividir la clase en varias clases. Es posible que tenga demasiada responsabilidad en un solo lugar. – Oded

+2

Solo usa parciales para clases generadas parcialmente. –

Respuesta

13

Separe su código en responsabilidades. Para cada responsabilidad, defina un solo tipo. Es decir, siga el Single Responsibility Principal. Hacerlo dará como resultado unidades de código más pequeñas, cada una de las cuales realiza una función muy específica. Esto no solo da como resultado archivos más pequeños, sino también un mejor diseño y capacidad de mantenimiento.

+0

¿Cómo se aplica esto a una clase de código subyacente de WPF? – Gabe

+0

@Gabe: la mayoría (a menudo, todas) de la funcionalidad de una vista reside en uno o más modelos de vista. Seguir a SRP implica que cada VM tiene una sola responsabilidad, en lugar de agrupar todo lo relacionado con la vista en una máquina virtual. Dicho esto, a veces es correcto tener código en el código subyacente, si está estrictamente relacionado con la vista (no lógica comercial) y no es compartido por otras vistas (no es un componente o comportamiento compartido). En ese caso, SRP todavía se mantiene porque la responsabilidad es "manifestar la vista", por así decirlo. –

2

Tiendo a agrupar propiedades, constructores, métodos y métodos de ayuda (métodos privados) junto con las regiones. Si tengo muchos métodos, creo más regiones según lo que hacen (especialmente bueno para sobrecargas). Y hablando de sobrecargas, intente minimizar su código con parámetros opcionales.

Por lo que yo entiendo, parcial significa que la clase existe en dos archivos separados. Los formularios web y los controles son parciales porque la otra "parte" del archivo es el archivo [p | c] x que lo acompaña.

+3

Regiones: simplemente di no;) –

+0

@Kent - no son tan malas. Solo quemaron mi casa una vez. – Oded

+3

El uso de regiones en archivos de clase es a menudo un signo de mal OOD ... ¡Y nunca oculte la complejidad! Hazlo menos complejo ;-) –

9

Si sus archivos son grandes porque contienen una sola clase/estructura que es grande, entonces esto es generalmente (pero no siempre) una pista de que su clase está tratando múltiples preocupaciones y puede ser refactorizada en un número menor, clases más especializadas.

1

Voy a la teoría de que si no puedes ver un método completo en una pantalla (es decir, tienes que desplazarte), debes dividir el método en otros métodos, ya sea en la misma clase o cuando se usará el código más de una vez en una clase de ayuda.

5

Si te entiendo, tu problema principal es que tus formularios terminan siendo demasiado grandes, lo que lleva a que las clases contengan demasiados códigos, lo que es bastante normal si tus formularios no son muy simples. La forma de intentar minimizar esto es usando User Controls ya que si mueve los controles a otras clases, también mueve el código a otras clases.

A veces puede hacer que sea un poco más difícil comunicarse entre los controles, pero eso generalmente está más que compensado por el hecho de que el código en cada clase será mucho más fácil de entender.

0

Usamos stylecop. Ayuda un poco porque impone una estructura en su código y un orden para lo que debería aparecer en donde. Por lo tanto, puede encontrar su camino alrededor de archivos más grandes de una manera más intuitiva.

Cuestiones relacionadas