archivo

Archivo de la etiqueta: clase

Cuando se habla de programación orientada a objetos se dice que un buen diseño es aquel que consigue una alta cohesión y un bajo acoplamiento. Como es lógico, estoy de acuerdo, no obstante de los dos conceptos la cohesión, tal vez por entenderse menos su utilidad, es el hermano pobre, es decir, si se tiene en cuenta alguno de los dos (algo que desgraciadamente no ocurre demasiado, ya que no se suele prestar suficiente atención a la calidad del diseño y de la codificación) se suele echar más en cuenta al acoplamiento, además de ser más inteligible por ser más evidentes los problemas existentes cuando el acoplamiento es alto.

La cohesión mide la relación entre los distintos elementos que componen una clase: atributos y métodos. Una baja cohesión da lugar a las denominadas clases tutti frutti, clases que pretenden hacer muchas cosas y diferentes.

Cuando se tienen clases con baja cohesión implica principalmente:

– Falta de comprensibilidad: La clase no sirve a un aspecto concreto, sino a muchos. Cuando pensamos en un objeto lo hacemos entendiendo que sus partes son necesarias para que exista su todo (es decir, las partes por sí solas tienen poca utilidad y es mediante su relación cuando dan entidad al objeto y hacen que en su conjunto (el todo) valga más que la suma de las partes por separado). Cuando tenemos clases cuyos elementos forman un todo, pero ese todo no es identificable con nada, nos encontraremos probablemente con clases que tienen una baja cohesión, con métodos que no guardarán relación con otros muchos de la misma y que servirán a propósitos distintos. Habrá que tener bien documentada la clase para mantenerla posteriormente, porque si la coge un equipo de desarrollo distinto o ha pasado mucho tiempo desde que se implementó resultará complicado entender para qué sirve y qué utilidad tienen muchos métodos y atributos de la misma.

– Dificulta la mantenibilidad: Además de por la disminución de la comprensibilidad de la clase, al tener más código del que debería tener, se incrementará en consecuencia la complejidad ciclomática de la misma y por tanto será más costoso realizar cambios.

– Dificulta la reutilización: Cuando tenemos una baja cohesión quiere decir que hemos modelado una realidad rara, un híbrido de muchas cosas. Se ha implementado una clase para algo muy específico y lo concreto pocas veces es reutilizable.

– Suelen tener un acoplamiento alto (en comparación a una cohesión baja): Tiene su lógica ya que la clase tendrá más métodos que si los diferentes objetos reales que están dentro de la misma se hubieran encapsulado en sus correspondientes clases. Más métodos implican por regla general llamadas a más métodos de clases y paquetes externos y en consecuencia un mayor acoplamiento.

– Tendentes a sufrir modificaciones: Como estas clases son híbridos de varias la probabilidad de tener que sufrir operaciones de mantenimiento crece (tanto como clases distintas pudieran contener en su interior), lo cual tiene su importancia sobre todo si tenemos en cuenta que este tipo de clases son más complicadas de mantener.

Una forma de medir la cohesión la tenemos con la métrica LCOM4, propuesta a partir de la métrica inicial LCOM1 de Chidamber y Kemerer. Esta métrica forma parte del conjunto de las mismas que calcula Sonar haciendo análisis estático de código.

ACD es otra métrica que mide el acoplamiento utilizando en este caso un elemento más genérico como es el componente que se puede definir como una unidad de división de una determinada aplicación. En base a esta definición tan generalista se podría considerar componente un paquete, las unidades de compilación (.java) o directamente considerar exclusivamente las clases.

Por regla general la asociación entre componente y unidad de compilación es la más común.

El cálculo de la métrica es sencillo ya que basta con calcular para cada componente el número de componentes de los que depende directa o indirectamente (a través de otros componentes), sumar cada uno de esos cálculos individuales y dividirlos entre el número total de componentes que se han analizado.

De esta manera se calcula la dependencia media de cada componente del programa, de manera que si por ejemplo tenemos un programa con 500 componentes y se obtiene un valor de ACD de 10, estaríamos indicando que cada componente depende de otros 50 componentes, por lo que un cambio en cualquiera de ellos podría provocar un comportamiento anómalo en él. Esto también puede ser visto de manera simétrica (ya que lo que se hace es calcular un valor absoluto de dependencia) de manera que un cambio en el componente podría afectar a otros 50 componentes.

Con el ejemplo expuesto en el anterior párrafo se puede comprender cómo de necesario resulta reducir el número de dependencias para conseguir un software lo más mantenible posible. De hecho esta métrica es considerada por muchos como una métrica indicativa del grado de testeabilidad que debe tener una determinada aplicación, ya que como es lógico a mayor dependencia, más probabilidad de efectos colaterales, mayor necesidad de pruebas.

NOC es otra de las métricas de Chidamber y Kemerer. Como no podía ser de otra forma, mide la complejidad de una clase desde un punto de vista diferente al del resto de métricas propuestas por estos autores. En este caso su cálculo se basa en contar el número de subclases que directamente heredan de la clase para la cual se calcula esta métrica.

Las subclases están acopladas con la clase de la que heredan, esto quiere decir que cuanto más clases hijas tenga una clase más prudencia hay que tener con cambios relacionados con el comportamiento y especificación de los métodos, ya que podría tener trascendencia sobre sus subclases. Por ese motivo, es necesario ser más exhaustivo en las pruebas de clases con un NOC alto, ya que cualquier problema en las mismas tiene un impacto importante en el programa. Por tanto, se puede deducir de esto que clases con un número de hijos elevado son más complicadas de mantener que otras con un número más bajo.

En el árbol de jerarquía de clases de un determinado programa resulta razonable que las clases situadas en los niveles más alto de la jerarquía tengan un valor de NOC superior a las clases que se encuentren en niveles inferiores, por ese motivo, la existencia de clases con un NOC alto en comparación con otras que se encuentran en niveles superior de la jerarquía, puede ser un indicador de un mal diseño de la clase o una utilización no adecuada de la herencia.

Por otro lado, clases con un NOC alto favorecen su comprensibilidad y la capacidad de implementación de nuevas reutilizaciones, ya que existe un número de clases de ejemplo donde se puede estudiar cómo han aplicado la herencia y como se ha reutilizado la clase.

La métrica RFC (Response for class) forma parte, como sucede con el caso de LCOM4 del conjunto de métricas enunciadas por Chidamber y Kemerer y que tienen como objeto obtener valores de referencia sobre el diseño orientado a objetos de una determinada aplicación.

En el caso de RFC lo que se mide es el acoplamiento entre clases, ya que su valor se obtiene a partir del número total de métodos que pueden potencialmente invocados en respuesta a un mensaje enviado a un objeto de la clase, es decir, el número de métodos que pueden ser ejecutados, cuando un método de la clase es invocado.

Dicho de otra manera, vendría a ser el número de métodos de una clase más el número de métodos de otras clases que son invocados por métodos de la clase (no contando más de una vez cada método, es decir si un método de una clase Y puede ser invocado por tres métodos de una clase X sólo se suma una unidad).

¿Qué es el acoplamiento? Es el grado de dependencia entre clases, por lo que cuando nos encontramos con situaciones donde el acoplamiento es alto crecerán las posibilidades de que el mantenimiento de las clases sea más complejo, ya que un cambio en el comportamiento de un método puede afectar a todos los que lo llaman y un cambio de interfaz del método puede provocar la necesidad de modificar el código de los métodos que lo llaman. También se considera que clases con un acoplamiento alto son más complicadas de entender y dificultan las tareas de testeo.

Un ejemplo de acoplamiento, fuera del mundo de la orientación a objetos, lo tenemos por ejemplo en la dependencia entre una aplicación y una serie de objetos (por ejemplo tablas o vistas) de un esquema de base de datos de otra, en este caso, sobre todo si las aplicaciones son gestionadas por equipos distintos y todavía no están lo suficientemente maduras, se correrá el riesgo permanente de que un cambio en el modelado de datos provoque que la aplicación que hace uso de ellos deje de funcionar adecuadamente. Además se podrá ver afectada por otros factores (cambio de instancia del esquema, cambio de sistema de gestión de base de datos, etc…).

El acoplamiento entre clases es inevitable, ya que los objetos cooperan y precisamente ofrecen servicios a través de sus APIs públicas para poder ser utilizados por otros. No se trata por tanto de eliminar el acoplamiento ya que eso no será posible, sino de intentar conseguir niveles de acoplamiento entre clases bajos, ya que permitirán reducir el número de efectos colaterales en el mantenimiento del sistema, haciendo más sencillas estas tareas y reduciendo las tasas de errores en tiempo de compilación y en tiempo de ejecución (cuando se cambian comportamientos a los métodos). Además de tener en cuenta en el diseño de las clases la existencia de un bajo acoplamiento, se pueden utilizar diferentes estrategias, como por ejemplo la creación de clases donde se centralice ese acoplamiento e incluso se implementen en las mismas fachadas que orquesten llamadas a métodos, de manera que tengamos algunas clases que sí tendrán valores altos o muy altos de RFC, pero que a cambio permitirá que se reduzcan el RFC de un buen número de clases.

A través de Sonar se puede obtener la media de RFC de la aplicación, de cada paquete de la misma y del conjunto de clases que la conforman. Se trata de medias aritméticas puras, sin aplicar ningún tipo de ponderación o umbral de valor de RFC de una clase.

Ahora viene la pregunta de siempre en este tipo de métricas, ¿a partir de qué valor se puede considerar que un RFC es demasiado alto?. Como sucede en el resto de métricas (salvo algunas excepciones como LCOM4) hay interpretaciones para todos los gustos, también como sucede con las otras, queda bastante claro cuando un RFC es muy alto y un RFC es muy bajo, por lo que “desde lejos” se pueden apreciar valores que pueden recomendar el estudio del nivel de acoplamiento de determinadas clases. Se pueden considerar aceptables valores de RFC <= 50.

También es posible obtener valores relacionando el RFC de una clase y su número de métodos (NOM). En programas realizados en Java Se pueden considerar aceptables valores de RFC/NOM <= 10.