Acoplamiento y Cohesión en Java

Buenos días, en esta entrada vamos a tratar el tema de la cohesión y el acoplamiento. Veremos como desarrollar código que implemente una
encapsulación mas estricta, pérdida de acoplamiento, y una alta cohesión en clases, y describir los beneficios que conlleva.

La cohesión y el acoplamiento, tienen que ver con la calidad del diseño OO (Orientado a objetos). En general, un buen diseño en la Orientación a
Objetos conlleva una perdida del acoplamiento y una gran cohesión. Como la mayoría de las discusiones sobre el diseño de la Orientación a Objetos, los
objetivos para una aplicación son:

• Facilidad de Creación
• Facilidad de mantenimiento
• Facilidad de ser mejorado

• Acoplamiento

  Vamos a empezar viendo un intento de al definición del acoplamiento. El acoplamiento es el grado en el cual una clase sabe acerca de otra
  clase. Si el único conocimiento que tiene una clase A sobre una clase B, es que la clase B ha expuesto a través de su interface, entonces la
  clase A y la clase B se dicen que tienen un acoplamiento bajo, lo cual es una buena idea. Si, en otro lado, la clase A se basa en partes de la
  clase B que no son parte de la interface de la clase B, entonces el acoplamiento entre las clases es mas estricta…lo cual no es buena idea. En otras palabras, si A conoce mas de lo que debería sobre la manera en la que B fué implementada, entonces A y B están acopladas estrictamente.

  Usando este segundo escenario, imagina que pasaría si la clase B fuera mejorada. Es bastante posible que el desarrolador que esté mejorando la
  clase B sin tener ninguna idea de la clase A, ¿Por qué iba a hacerlo?. El desarrollador de la clase B debería sentir que cualquier mejora que no
  rompa la interface de la clase debería ser seguro, por lo que puede cambiar algunas partes que no pertenezcan a la interface de la clase, lo cual
  entonces haría que la clase A se rompiera.

  En el otro extremo estaría el caso en el que la clase A conociera cosas que no pertenecen a la API de la clase B, y la clase B conociera cosas que
  no son de la API de la clase a…lo cual sería realmente MALO. Si cualquiera de las clases no se han cambiado nunca, hay una posibilidad de que otra
  clase la rompa. Vamos a ver un ejemplo obvio sobre el acoplamientoe stricto, lo cual ha sido habilitado debido a la mala encapsulación.

   class DoTaxes{
      float rate;
      float doColorado(){
          SalesTaxRates str = new SalesTaxRates();
          rate = str.salesRate;   // Esto deería ser la llamada a un método
                                  //rate = str.getSalesRate("CO");
          return rate;
      }
  }
  
  class SalesTaxRates{
      public float salesRate;         // debería ser private
      public float adjustedSalesRate; // debería ser private
      
      public float getSalesRate(String region){
          salesRate = new DoTaxes().doColorado();
          // Calculos
          return adjustedSalesRate;
      }
  }
              

  Todas las aplicaciones de la OO no triviales son un conjunto de clases e interfaces trabajando conjuntamente. Idealmente, todas las interacciones entre objetos en un sistema OO debería usar las APIs, en otras palabras, los “contratos”, de los objetos de las respectivas clases. Teóricamente, si todas las clases en una aplicación tienen APIs bien definidas, entonces debería ser posible para todas las interacciones internas de la clase a usar estas APIs exclusivamente. Un aspecto del buen diseño de una clase y una API es que las clases deberían estar bien encapsuladas.

• Cohesión

  Mientras que el acoplamiento tiene que ver con como las clases interactuan unas con otras, la cohesión es todo sobre como una clase singular está diseñada. El término cohesión es usado para indicar el grado en el cual una clase es individual , y tiene un propósito bien enfocado. Guardemos en la mente que la cohesión es un concepto subjetivo. Mientras más enfocada esté una clase, mas alta será su cohesión (lo que es una buena idea). Los beneficios clave de una alta cohesión es que tales clases son típicamente mas fáciles de mantener que clases con una baja cohesión. Otro beneficio de la alta cohesión es que las clases con un propósito bien definido tienden a ser mas reutilizables por otras clases. Vamos a ver un ejemplo en pseudocódigo:

   class BudgetReport{
      void connectToRDBMS(){ }
      void generateBudgetReport() { }
      void saveToFile() { }
      void print(){ }
  }
              

  Ahora imaginemos que nuestro administrador viene y nos dice:

  Hey ¿Sabes la aplicación sobre las cuentas en las que estamos trabajando? Los clientes han decidido que van a querer que se genere un informe de proyección de ingresos, y tambien quieren que hagan un informe del inventario tambien. Haz que todos esos reportes le dejen escoger una base de datos, escoger una impresora y guardar esos informes generados en ficheros..”

  En vez de poner todo el código de imprimir en una clase, probablemente sería mejor si empezaramos con este diseño desde un principio:

  class BudgetReport{
      Options getReportingOptions(){}
      void generateBudgetReport(Options o){}
  }
  
  class ConnectToRDBMS(){
      DBconnection getRDBMS(){}
  }
  
  class PrintStuff{
      PrintOptions getPrintOptions(){}
  }
  
  class FileSaver{
      SaveOptions getFileSaveOptions(){}
  }
              

  Este diseño es mucho mas cohesivo. En vez de tener una clase que hace todo, hemos roto el sistema en 4 clases principales, la cual cada una es mas específica, o cohesiva. Por esta razón, las clases son mas especializadas, y son mas reutilizables.

Hasta aquí un interesante artículo sobre la manera de trabajar y el pensamiento que debemos adoptar al desarrollar clases, para mantener un fácil uso de nuestras clases, un fácil mantenimiento y una manera fácil de reutilizarlas.

Sin mas, cualquier aporte o corrección es bienvenido.

Saludos!!!