¿Es común usar clases parciales para lograr 'modularidad'?

Recientemente me encontré con una situación en nuestra base de código donde un equipo diferente creó una 'clase de dios' que contiene alrededor de 800 métodos, divididos en 135 archivos como una clase parcial.

Le pregunté al otro equipo sobre esto. Si bien mi reacción instintiva fue atacarlo desde la órbita, insisten en que es un buen diseño, una práctica común, y que promueve la 'modularidad' y la 'facilidad de implementación' porque los nuevos desarrolladores pueden atornillar la funcionalidad sin casi ningún conocimiento del resto del sistema.

¿Es esto realmente una práctica común o de alguna manera una buena idea? Me inclino a tomar medidas inmediatas para derribar a esta bestia (o al menos evitar que siga creciendo), pero estoy dispuesto a creer que estoy equivocado.

Esto no es de ninguna manera una buena idea.

Existen clases parciales para ayudar al diseñador de formularios. Usarlos por cualquier otro motivo (y posiblemente para su propósito previsto, pero es un asunto diferente) es una mala idea, ya que conduce a clases infladas que son difíciles de leer y comprender.

Míralo de esta manera: si una clase de dios con 800 métodos en un archivo, donde sabes dónde está todo, es algo malo, y creo que todos estarían de acuerdo en que es así, entonces, ¿cómo puede una clase de dios con 800 métodos? distribuido en 135 archivos, donde no sabes dónde es posible que todo sea algo bueno.

Entonces la pregunta era:

¿Es esto realmente una práctica común o de alguna manera una buena idea?

Entre las respuestas disponibles actualmente se encuentra un rotundo no . Así que hay algunas otras cosas en las que podría intervenir, como; incluso el código de procedimiento puede hacerse modular e incluir todo, pero el fregadero de la cocina no es la forma de lograr la modularidad. Lo que sí hace una clase gigante dividida en parciales, todo se suma en un gran desastre.

Sin embargo, esa pregunta es una pista falsa para la parte crítica real de lo que se ha perdido; ya que el OP también tiene lo siguiente que decir sobre la situación:

(...) Si bien mi reacción intestinal fue sacudirlo desde la órbita, insisten ...

(...) Me inclino a tomar medidas inmediatas para derribar a esta bestia (o al menos evitar que siga creciendo), pero estoy dispuesto a creer que estoy equivocado.

¡CALMA!

Esto es algo que haría que mi monóculo figurativamente hablando cayera en mi taza de té figurativa.

He estado en situaciones similares y déjame decirte: NO caigas en la urgencia de hacerlo. Claro, puedes dejar el Nuke Hammer of Justice en el equipo, pero antes de hacerlo, por favor hazte el siguiente enigma:

¿Qué pasará si le dice al equipo que su código chupa y al cabrón ?

(... o algo así pero de manera menos ofensiva, en realidad no importa porque se ofenden independientemente de lo que hagas si decides ir con toda su fuerza)

¿Cuál es la situación actual con la base del código? ¿Está funcionando? Entonces tendrás grandes problemas para explicarles a sus clientes que su código esencialmente apesta . No importa qué razones tengan: mientras funcione, a la mayoría de los clientes no les importa cómo está organizado el código.

También ponte en sus zapatos, ¿qué harían? Déjame divertirte con el siguiente resultado muy posible:

Miembro del equipo n. ° 1: "Entonces este tipo nos dice que lo hemos estado haciendo mal durante los últimos años".

Miembro del equipo # 2 y # 3: "Qué idiota".

Miembro del equipo influyente # 4: "No se preocupe por eso, simplemente iré a la gerencia y lo reportaré como un acoso".

¿Ves lo que el miembro del equipo influyente # 4 hizo allí? Fue a la gerencia y redujo su karma en la empresa. Él podría ser estadounidense-italiano, diciéndole a todos que no se preocupen por eso, pero entonces sería racista al respecto.

Pintar al equipo infractor en una esquina y dejarlos admitir que lo hicieron mal durante tanto tiempo también es una mala idea y lleva a lo mismo. Perderás el respeto y algo de karma político de oficina.

Incluso si logró que un grupo de personas firmen esto, para "enseñarle una lección al equipo", recuerde que lo está haciendo con personas bastante inteligentes que aparentemente hacen algunas cosas. Una vez que el código será reescrito / refactorizado / tratado / lo que sea que surja y surjan problemas, usted será responsable de ser el iniciador .

Ser adversario sobre situaciones como esta es principalmente un juego de perder / perder, ya que corre el riesgo de convertirse en un círculo vicioso de juegos de culpa. Este es un resultado subóptimo para esta situación. Incluso si ganas, de repente te entregan el desastre que otra persona hizo.

Hay otras formas (mucho más maduras)

Una vez tuve una situación similar, pero luego recibí una flecha en la rodilla. Entonces, después de un tiempo con esa repentina flecha que altera la carrera en mi mente, recibí un libro Driving Technical Change de Terrence Ryan . Enumera varios patrones de escépticos, el tipo de personas que no actúan sobre buenas ideas. Es muy probable que sean aplicables en el caso del OP:

• Los desinformados: realmente no sabían que había otras formas o simplemente no entendían. Los desarrolladores junior generalmente encajan en esta categoría, pero no necesariamente. (Para ser honesto: he conocido desarrolladores junior que serían más brillantes que esto).
• El rebaño: sabían mejores técnicas que usar clases parciales, pero no sabían que estaban permitidos.
• The Cynic: simplemente les gusta argumentar que tener clases parciales es mejor que su idea solo por discutir. Es fácil hacerlo en una multitud en lugar de pararse frente a una multitud.
• The Burned: por alguna extraña razón, no les gusta crear nuevas clases, lo más probable es que lo perciban como demasiado difícil.
• The Time Crunched: están tan ocupados que no pueden molestarse en arreglar su código.
• The Boss - Piensan: "Bueno, funciona, ¿por qué molestarse?"
• The Irrational: Ok, están completamente locos.

El libro continúa con una lista de estrategias, etc., pero en el caso del OP es una cuestión de persuasión. Ir a la cabeza con los hechos sobre el antipatrón no es suficiente.

Si le interesa aumentar la calidad del código, al menos brinde al equipo infractor la oportunidad de reiterar y rectificar su propio desorden . Personalmente, trataría de influirlos escuchando y haciendo preguntas principales, dejar que cuenten su historia:

• ¿Qué está haciendo exactamente su clase de dios?
• ¿Han tenido algún problema? ¿Tienen algún error? Sugiera soluciones sanas sin decirles que lo hagan.
• Si usted es un usuario de esta clase de dios como API: ¿Hay formas más simples de usar el código que usar todo? Sugiera ejemplos más simples, vea cómo reaccionan.
• ¿Se puede cambiar alguna funcionalidad con otra, sin tener que escribir la función?
• ¿Necesitan alguna capacitación? ¿Puede convencer a la gerencia para que lo haga o almorzar sobre patrones y prácticas?

... y así. Déles pequeñas sugerencias para que puedan avanzar. Lleva tiempo y necesitará un poco de grasa en el codo, pero la paciencia y el trabajo duro son una virtud, ¿verdad?

La página de Clases y métodos parciales de MSDN sugiere dos situaciones para usar clases parciales:
1. Para dividir una clase gigante en múltiples archivos separados.
2. Tener un lugar para colocar el código fuente generado automáticamente.

2 es muy utilizado por Visual Studio (por ejemplo, para archivos aspx y winforms). Este es un uso razonable de clases parciales.

1 es lo que está haciendo tu equipo. Diría que usar clases parciales es una forma perfectamente razonable de lograr la modularidad cuando se tienen clases gigantes, pero tener clases gigantes en sí mismo no es razonable. En otras palabras, tener una clase gigante es una mala idea, pero si vas a tener una clase gigante, las clases parciales son una buena idea.

Aunque si puede dividir inteligentemente una clase en archivos separados para que trabajen diferentes usuarios, ¿no puede dividirla en clases separadas?

Entonces, al final, están haciendo un desarrollo procesal normal sin ninguna pieza de OOP. Tienen un espacio de nombres global con todos los métodos, variables y demás.

O persuadirlos de que lo están haciendo mal o salir de allí.

Una clase de utilidad contiene métodos que no se pueden combinar con otros métodos para crear una clase. Si tiene más de 800 métodos, divididos en 135 archivos, parece probable que alguien haya logrado encontrar algunos métodos comunes ...

El hecho de que tenga una clase de utilidad no significa que no pueda tener otra clase de utilidad.

Incluso si tiene 800 métodos en su mayoría no relacionados, la solución no es una gran clase y muchos archivos. La solución es un espacio de nombres, algunos subespacios de nombres y muchas clases pequeñas. Esto es un poco más de trabajo (tienes que encontrar un nombre para la clase y el método). Pero hará que su vida sea más fácil cuando llegue el momento de limpiar este desorden, y mientras tanto hará que intellisense sea más fácil de usar (es decir, más fácil descubrir dónde es un método para usarlo).

Y no, esto no es común (más el número de archivos que el número de funciones gratuitas).

No me gusta esto en absoluto. Sin embargo, tal vez las clases parciales tuvieron sentido para los desarrolladores durante el desarrollo porque permitieron el desarrollo concurrente de este gran número de métodos, especialmente si no hay mucha dependencia entre ellos.

Otra posibilidad es que esas clases parciales se construyeron para modificar una clase principal generada automáticamente. Si este es el caso, uno no debe tocarlos, de lo contrario, el código personalizado se eliminaría al volver a generar.

No estoy seguro de que alguien pueda mantener esto con facilidad sin algún estudio. Ahora, si lo matas, la cantidad de métodos no disminuirá. La cantidad de métodos y complejidad, para mí, es el verdadero problema. Si los métodos realmente pertenecen a la clase, entonces tener 1 archivo enorme no te facilitará la vida, especialmente en mantenimiento, de hecho, puede ser más propenso a errores exponer todo este código a errores tontos como la búsqueda con comodines y reemplazar.

Así que ten cuidado y justifica la decisión de matar. Además, considere qué pruebas se requerirán.

Está perfectamente bien desde una perspectiva de diseño práctica, suponiendo que los 135 archivos realmente agrupen métodos similares a lo que harían las clases tradicionales. Es solo un promedio de 6 métodos por archivo. Definitivamente no es la forma más popular o tradicional de diseñar un proyecto. Intentar cambiarlo solo creará un montón de problemas y la enfermedad no tendrá ningún beneficio real. Hacer que el proyecto se ajuste a los estándares OO creará tantos problemas como se resuelvan. Es un asunto completamente diferente si los archivos múltiples en realidad no proporcionan separaciones significativas.

Más allá de las respuestas ya señaladas, las clases parciales pueden ser útiles en un diseño en capas donde desea organizar la funcionalidad que cruza su jerarquía de clases en archivos específicos de capa separados. Esto permite utilizar el explorador de soluciones para navegar por la funcionalidad por capa (por organización de archivos) y la vista de clase para navegar por la funcionalidad por clase. Preferiría usar un lenguaje que admita mixins y / o rasgos, pero las clases parciales son una alternativa razonable si se usan con moderación, y no deberían ser un reemplazo para un buen diseño de jerarquía de clases.