Los conceptos de la POO

1. Agregación

Una agregación es una relación entre dos clases donde una "posee" a otra. En UML, esta relación se simboliza con una línea que conecta las dos clases, donde el final vinculado a la clase del "contenedor" termina con un diamante vacío. También es posible especificar la cardinalidad de esta relación. En UML, generalmente se elige una cardinalidad entre los siguientes valores:

Algunas cardinalidades pueden ser más precisas (2..5 por ejemplo), pero ciertas herramientas de modelado solo permiten los cuatro valores enumerados anteriormente.

Si se especifica una cardinalidad desde el contenido hasta el contenedor, proporciona información sobre la cantidad de contenedores potenciales que pueden poseer el contenido (consulte el siguiente ejemplo).

La cardinalidad en UML es importante...

1. Herencia simple

Cuando una clase hereda de otra, entonces la clase llamada "derivada" (o "hija") recupera todos los miembros de la clase "base" (o "madre"), posiblemente puede volver a implementarlos (hablamos de "especialización "o" sobrecarga ") o añadir nuevos.

En UML, una herencia se representa de la siguiente manera:

Un Circulo es una Forma: hereda todos sus atributos (centro_x, centro_y), todos sus métodos (trasladar()) y los completa (radio).

La principal ventaja de la herencia es poder factorizar la lógica "empresarial" de diferentes clases, en una sola: la clase base. Esta es la que agrupa los comportamientos genéricos y depende de las diferentes clases derivadas implementar los comportamientos específicos. Sin embargo, estos conservan la posibilidad de invocar los mismos métodos y acceder a los mismos atributos que la clase madre.

En algunos casos, no tiene sentido propagar a las clases hija ciertos miembros (atributos de cálculo, métodos de utilidad, etc.). Por tanto, es posible precisar cuáles son los miembros que se desea heredar en las clases derivadas, modificando su visibilidad. Como recordatorio: las clases derivadas pueden acceder automáticamente a los miembros públicos y protegidos, mientras que a los miembros privados no. Nuevamente, el control de la información es esencial en POO, y si es posible evitar que una clase tenga acceso a datos que no necesita, entonces se debe hacer.

2. Clase abstracta

Opcionalmente, una clase se puede declarar abstracta, es decir, no representa un concepto de negocio que se pueda manejar como tal.

No se puede dibujar una Forma. Se puede dibujar un Cuadrado, un Círculo, una línea cerrada a mano alzada, pero no una Forma. Una Forma es una generalidad, una forma de designar estas diferentes clases bajo un solo nombre, pero no representa un caso concreto en sí mismo.

El interés de la clase abstracta es aprovechar las ventajas de la herencia, es decir, factorizar los datos y los comportamientos...

1. Estructura vs. comportamiento

Desde el comienzo de este libro, solo se han utilizado diagramas de clases. En UML, hay varios tipos diferentes de diagramas que se pueden dividir en dos categorías:

Dado que aún no se ha visto ningún diagrama de comportamiento, las siguientes secciones presentarán dos: el diagrama de casos de uso y el diagrama de secuencia. Como parte de una introducción a la POO, estos dos diagramas son los más relevantes porque manipulan los conceptos principales de POO estar demasiado desarrollados. Su presentación no será lo más completa posible porque esto iría más allá del alcance de este libro. Sin embargo, debería ser suficiente para poder utilizar estos diagramas en proyectos.

2. Diagrama de casos de uso

No debemos olvidar que el software no es un fin: es un medio, una herramienta para realizar tareas, funciones que responden a una necesidad de negocio....

1. Clase simple

Enunciado: modelar una clase para la que queremos que pueda recibir una lista de objetos cualesquiera, para poder recuperar posteriormente su longitud (el número de objetos en la lista). El esquema debe enumerar explícitamente todos los miembros necesarios.

Solución

La clase Contador tiene un método contar() que recibe una lista de objetos como argumento. No devuelve nada, porque el enunciado no menciona el hecho de devolver el número de elementos inmediatamente, sino más tarde, lo que implica la necesidad de almacenar este resultado para un uso futuro. De ahí la presencia de un atributo numero_elementos, ni público ni protegido, sino privado, para evitar el riesgo de que una clase externa pueda cambiar su valor.

Si el método contar() se encarga de calcular el valor del atributo, la responsabilidad de actualizar este contador recae únicamente en su descriptor de acceso de escritura, tan acertadamente llamado escribir_numero_elementos, que también es privado. De hecho, la encapsulación también se aplica dentro de una clase. El principio de responsabilidad única de una clase también debe ser válido para los métodos que la componen, exactamente por las mismas razones: es más fácil dar soporte al cambio si cada "actor" solo tiene un único rol. En esta clase Contador, si asumimos que hay n métodos que modifican directamente numero_elementos, cambiar el atributo implicaría modificar la implementación de estos n métodos para reflejar este cambio. Si estos n métodos usaran un descriptor de acceso, entonces un cambio en el atributo que desean escribir no tendría ningún impacto. La separación de responsabilidades implica un menor desarrollo durante los cambios evolutivos. 

Finalmente, el acceso de lectura recuperar_numero_elementos() devuelve el valor del atributo en cuestión, y es público porque es el papel de la clase Contador exponer este valor.

2. Relaciones entre clases

Enunciado: Para cada uno de los siguientes pares de conceptos, indique si, desde el punto de vista del modelado de software, estos pares deben estar vinculados por una agregación o una composición, y por qué.