[Anti-Patterns] Contenedor Mágico
La motivación de quien codifica este código radica en el afán de maximizar el reuso de una rutina mediante una generalización excesiva. Esto lo lleva a intentar la panacea de lograr la función que "sirve para todo".
Un ejemplo común se ve con frecuencia en los cursos de programación universitarios en los que los alumnos crean sus funciones "LlenarGrilla(….)" las cuales les permiten completar grillas (controles visuales) de muchas formas diferentes, ordenadas según ciertas columnas, con filas coloreadas según algunas condiciones, con formatos por columnas, ancho por columnas, con bordes o sin ellos, editables o no, etc. Para lograr esto, una función "LlenarGrilla(….)" debe recibir un número significativo de parámetros, muchos opcional, muchos arrays de objetos, algunos booleanos, otros strings y así según las funcionalidades que los alumnos deseen.
El código final resulta en extremo complejo y dificil de mantener. Cuando surge un nuevo requerimiento, que la función no contempla, solo queda agregar más parámetros a su firma e intentar introducir la nueva característica. Este proceso se repite hasta que se vuelve inviable.
Lo puse en wikipedia (Contenedor mágico) porque no estaba pero alguién en cualquier momento lo va a mejorar.
Lucas Ontivero
Booteando ando 
Que recomendarias para tal caso y lograr que el que la situación sea manejable?
Saludos
Andés
La recomendación es ESTUDIAR porque como dije, así programan los newbies. Pero hay un problema, nadie te enseña a programar. Claro, también existe gente que no aprende nunca porque no tiene alma de programador o no le interesa. Hay mucha gente que lleva muchos años como programadores y programan horrible así que la experiencia ayuda pero se necesita un esfuerzo extra para aprender e incorporar "recomendaciones" de programación. También alguien puede programar alguna cosa de esa manera porque "vino así", es decir, yo no pienso refactorizar una clase de 36.307 lineas de código heredado sino que simplemente le voy a agregar/quitar/modificar lo que haga falta y listo. Es como que te pidan agregarle un piso a la tore de pisa, como lo harias? enderesarias la torre?.
En síntesis, estudiar, seguir y probar recomendaciones de gente que sepa más que uno, creo que eso no se si es suficiente pero seguro que es necesario.
Saludos.
Tenés muchísima razón. Con el "LlenarGrilla" me haz hecho acordar de varias cosas parecidas que ví en el pasado. Es muy común que por el hecho de realizar "Superfunciones" terminen escribiendo miles de líneas con centenas de if para cada uno de los casos. En este caso es muy normal verlas con Visual Basic, que permite los parámetros opcionales. Si usás correctamente la sobrecarga de métodos y un buen diseño se puede evitar este tipo de males.
Si, es un punto importante. Lo de VB es claro, no teniamos sobrecarga pero podiamos hacer otras funciones como un asqueroso LlenarGrilla2,3,4, etc. Despues de todo la sobrecarga real no existe y es solo un trucho para llamar de igual manera a mas de un método, en el IL o en el ASM generado por un c++ los métodos sobrecargados tienen distintos nombres.
Otra es mediante herencia, un GrillaBase con un método llenar (o Fill) que heredan otras grillas más especificas que sobreescriben el método, incluso mejor sería que la misma estrategia se aplicara por fila, una clase RowBase……
Existen muchas alternativas más peo el problema es que se usan alternativas no orientadas a objetos!!! a veces por culpa del lenguaje elegido.