Hola a todos.

(no estoy seguro de si éste es el sub-foro adecuado para esta esntrada. Si hay otro mejor decídmelo.)

Os veo hablar muy a menudo de las "métricas", así que hace un par de semanas me puse a leer qué eran y cuáles son los objetivos que buscan. Sólo leerlo me ha ayudado mucho a mejorar la forma de afrontar un proyecto. Me he puesto a aplicar alguna de las ideas a un proyectito y el resultado ha sido dividir una Mega-Clase en cinco clases menores (estoy pensando si sacar todavía una sexta).

Efectivamente, la Mega-Clase tenía demasiados cometidos. Me fue sencilla la división porque en el código tenía más o menos agrupados los métodos según su funcionalidad (estaba pidiendo a gritos que la dividieran).

Tras hacerlo se me ha ocurido comprobar qué clases llaman a métodos de qué otras y, sorpresa, he descubierto la primera gran ventaja de la división en clases: Tres clases son independientes y no llaman a métodos de las demás, Así que tengo tres "puñaditos" de funciones que puedo incluir en un proyecto sin tener que arrastrar todas las demás.

Las dos clases restantes se apoyan en las tres anteriores y también se llaman entre ellas (en ambas direcciones). En este punto tengo una duda:
Llamemos a estas clases A y B: La clase A llama a muchos métodos de B en muchas partes del código y B llama a ún único método de A sólo en dos partes del código. Dicho método de A es corto y sencillo y se me ocurre que copiando su código en B puedo eliminar la dependencia de B respecto de A, para que sólo A dependa de B...

Tengo un par de dudas: 1- si es conveniente o no eliminar la dependencia de B
  2- si existen recomendaciones sobre este tipo de "dependencias" (si se les puede llamar así) o si hay alguna teoría o metodología de diseño que indique si es mejor repetir el código en B o dejar todo como está... (Encuentro que todo lo que leo sobre diseño de proyectos y metodologías me ayuda a mejorar el código, así que me leeré lo que sea que me recomendéis)

Muchas gracias

Gracias por el consejo, Chuidiang. La verdad es que la primera opción era la mejor y no sólo por ser la más sencilla. Tras pensarlo un poco el "metodoDeMarras" encajaba mejor en la clase "B" (al igual que otro que se le parece..). Parece como si el proyecto me estuviera hablando a mí diciéndome cómo debo escribirlo! 

¿Dónde puedo aprender más sobre este tipo de cosas?

Eres una mina...

Hola:

Uno de los principios básico es no repetir código (busca cosas sobre DRY "Don't repeat yourself"), así que en principio no es bueno repetir ese método en A y B.

Tampoco es bueno que dos clases dependan una de la otra, es mejor diseño si una depende de la otra y no al revés (la más compleja o de más alto nivel debería depender de la más sencilla o de más bajo nivel y no al revés), así que sí sería conveniente eliminar esa dependencia. Hay muchas posibilidades, tantas como imaginación tengas, elige la que veas mejor. Ahí van unas cuantas.

Si es posible, la más sencilla, mueve el código de ese método de una clase a otra, y que A llame a B para usar ese método. Esa dependencia ya la tienes.

Piensa en una tercera clase para ese método y lo que necesite, así A y B dependerán de esa tercera clase más pequeña, pero B no dependerá de A.

Uso de interfaces. A puede implementar una interface que te hagas y que tenga ese método. B vería a A pero como interface

Code: [Select]

public UnaInterface {
   public void elMetodoDeMarras (....);
}


Code: [Select]

public class A implements UnaInterface {
    public void elMetodoDeMarras (....) {
    }
}


Code: [Select]

public class B {
   UnaInterface a;
   public B (UnaInterface a) {
      this.a = a;
   }
}

Se bueno.

Excelente información, me ha sido de mucha ayuda
"Adriana"