Esto no es realmente una respuesta sino un comentario largo (porque estas respuestas ya se han presentado).
Descubrí que esforzarme religiosamente por dos factores: las interfaces limpias y utilizables y la no repetición han mejorado mucho mi código y con el tiempo me han convertido en un programador mucho mejor.
A veces, eliminar código redundante es DIFÍCIL, te obliga a crear algunos patrones difíciles.
Por lo general analizo lo que DEBE cambiar y luego ese es mi objetivo. Por ejemplo, si está realizando una GUI en un cliente para actualizar una base de datos, ¿qué necesita para agregar "Otro" (otro control vinculado a la base de datos?) Debe agregar una fila a la base de datos y necesita la posición del componente, eso es todo.
Entonces, si eso es lo mínimo, no veo NINGÚN código en eso, DEBES poder hacerlo sin tocar tu base de código. Esto es sorprendentemente difícil de lograr, algunos juegos de herramientas lo harán (generalmente de manera deficiente), pero es un objetivo. ¿Qué tan difícil es acercarse? No terriblemente Puedo hacerlo y lo he hecho con código cero de un par de maneras, una es etiquetar nuevos componentes GUI con el nombre de la tabla en la base de datos, otra creando un archivo XML: el archivo XML (o YAML si no te gusta) XML) puede ser realmente útil porque puede vincular validadores y acciones especiales al campo, haciendo que el patrón sea extremadamente flexible.
Además, no lleva más tiempo implementar las soluciones correctamente; para cuando ya ha enviado la mayoría de los proyectos, en realidad es más barato.
Puedo señalar que si dependes mucho de Setters & Getters ("Bean Patterns"), Genéricos & Las clases internas anónimas probablemente NO ESTÁN codificando genéricamente de esta manera. En los ejemplos anteriores, tratar de forzar en cualquiera de estos realmente te jodirá. Setters & Los programadores te obligan a usar el código para los nuevos atributos, los genéricos te obligan a crear instancias de las clases (que requieren código) & Las clases internas anónimas tienden a no ser fáciles de reutilizar en otros lugares. Si realmente está codificando genéricamente, estas construcciones de lenguaje no son malas, pero pueden dificultar la visualización de un patrón. Para un ejemplo totalmente absurdo:
user.setFirstName(screen.getFirstName());
user.setLastName(screen.getLastName());
Se ve bien, no es en absoluto redundante, al menos no de una manera que puedas arreglar, ¿verdad? Pero hace que agregues una línea cuando quieres agregar un "Segundo nombre", por lo que es "Código redundante"
user.getNameAttributesFrom(screen);
No necesita código nuevo para esta tarea; simplemente requiere que algunos atributos en "pantalla" estén etiquetados con un atributo "Nombre", pero ahora no podemos copiar la dirección, ¿qué tal esto?
user.getAttributesFrom(screen, NAME_FIELDS, ADDRESS_FIELDS);
Mejor, una var-args le permite incluir un grupo de atributos (de una enumeración) para recopilar desde la pantalla; aún tiene que editar el código para modificar los tipos de atributos que desea. Tenga en cuenta que "NAME_FIELDS" es una instancia de enumeración simple: los campos en "pantalla" están etiquetados con esta enumeración cuando están diseñados para colocarlos en la (s) categoría (es) correcta (s) - no hay tabla de conversión.
Attribute[] attrs=new Attributes[]{NAME_FIELDS, ADDRESS_FIELDS, FRIENDS_FIELDS};
user.getAttributesFrom(screen, attrs);
Ahora lo tienes donde simplemente estás cambiando "Datos". Aquí es donde normalmente lo dejo, con los datos en el código, porque es "lo suficientemente bueno". El siguiente paso es externalizar los datos si es necesario, para que pueda leerlos desde un archivo de texto, pero rara vez lo es. Las refactorizaciones se "enrollan" mucho como esta una vez que te adquieres en el hábito, y lo que acabo de hacer ^ creó una nueva enumeración y patrón que terminará rodando en muchas otras refactorizaciones.
Finalmente, tenga en cuenta que las buenas soluciones genéricas para problemas como este NO son dependientes del idioma. He implementado una solución sin código por ubicación para analizar una GUI de texto desde la línea de comandos de un enrutador, actualizarla en la pantalla y volver a escribirla en el dispositivo, en VB 3. Solo requiere dedicación al principio de no escribir código redundante, nunca, incluso si tiene que escribir el doble de código para hacerlo.
La Interfaz Limpia (Completamente Factada & no permite que pasen cosas ilegales) también es importante. Cuando factoriza una interfaz entre dos unidades de código correctamente, le permite manipular el código en ambos lados de la interfaz con impunidad y permite que los nuevos usuarios implementen las interfaces de forma limpia.