Encapsulamiento y Ocultación de la Información
La ocultación de información aporta las siguientes ventajas a un proyecto de software:
Desarrollo Independiente
Supongamos un sistema implementado mediante las clases C1, C2, …, Cn. Si estas clases ocultan sus decisiones internas de diseño, es más fácil asignar su implementación a diferentes desarrolladores. En consecuencia, se reducirá el tiempo de implementación del sistema.
Modificabilidad
Supongamos que descubrimos que la clase Ci tiene problemas de rendimiento. Si los detalles de implementación de Ci se ocultan al resto del sistema, será más fácil sustituirla por otra clase Ci’, que utiliza una estructura de datos y un algoritmo más eficientes. También es menos probable que este cambio provoque errores en otras clases.
Comprensibilidad
Supongamos que la empresa contrata a un nuevo desarrollador. Así, se le puede asignar que trabaje sólo en algunas clases. En otras palabras, no necesitará entender todo el sistema, sólo la implementación de las clases de las que es responsable.
Sin embargo, ocultar información no significa que una clase deba encapsular todos sus datos y código. Ciertamente, esto daría lugar a una clase sin utilidad. De hecho, una clase útil debe tener métodos públicos, es decir, métodos que puedan ser llamados y utilizados por los clientes. También decimos que los miembros públicos de una clase definen su interfaz. Este concepto es muy importante, ya que establece la parte visible de la clase. Las interfaces deben ser estables, ya que los cambios en la interfaz de una clase pueden provocar actualizaciones en los clientes.
Cohesión
La implementación de cualquier clase debe ser cohesiva, lo que significa que las clases deben implementar una única función o servicio. Es decir, todos los métodos y atributos de una clase deben contribuir a la implementación del mismo servicio (única responsabilidad en el sistema). La cohesión tiene las siguientes ventajas:
- Facilita la implementación, comprensión y mantenimiento de una clase.
- Facilita la definición de un único desarrollador para el mantenimiento de una clase.
- Facilita la reutilización y las pruebas, ya que es más sencillo reutilizar y probar una clase cohesionada que una clase responsable de muchas tareas.
Métrica relacionada: LCOM
LCOM (Lack of Cohesion of Methods) asume que, en una clase cohesiva, cualquier par de métodos debe acceder al menos a un atributo común. En otras palabras, lo que contribuye a la cohesión de una clase es el hecho de que sus métodos accedan a los mismos atributos.
Acoplamiento
El acoplamiento se refiere a la fuerza de la conexión entre dos clases. Decimos que existe un acoplamiento aceptable entre la clase A y la clase B cuando:
- La clase A sólo utiliza métodos públicos de la clase B.
- La interfaz proporcionada por B es estable, tanto sintáctica como semánticamente. Esto significa que las firmas de los métodos públicos de B no cambian con frecuencia, ni tampoco el comportamiento de estos métodos. Por lo tanto, los cambios en B rara vez afectarán a A.
Por el contrario, existe un acoplamiento deficiente entre la clase A y la clase B cuando los cambios en B pueden afectar fácilmente a A. Esto ocurre principalmente en las siguientes situaciones:
- Cuando las clases A y B comparten una variable global o estructura de datos, por ejemplo, cuando B cambia el valor de una variable global utilizada por A.
- Cuando la clase A accede directamente a un fichero o base de datos de la clase B.
- Cuando la interfaz de B no es estable. Por ejemplo, los métodos públicos de B cambian de nombre con frecuencia.
El acoplamiento deficiente se caracteriza por el hecho de que la dependencia entre las clases no está mediada por una interfaz estable. Por ejemplo, es difícil evaluar el impacto que la actualización de una variable global puede tener en otras partes del sistema. En cambio, cuando se actualiza una interfaz, este impacto es más explícito.
Métrica relacionada: CBO
CBO (Coupling Between Objects) es una métrica para medir el acoplamiento estructural entre dos clases. Dada una clase A, CBO cuenta el número de clases de las que A tiene dependencias sintácticas (o estructurales). A depende de una clase B cuando:
- A llama a un método de B
- A accede a un atributo público de B
- A hereda de B
- A declara una variable local, un parámetro o un tipo de retorno de tipo B
- A captura una excepción de tipo B
- A lanza una excepción de tipo B
- A crea un objeto de tipo B.