Tema 4: Programación orientada a objetos. UML

Conceptos de la Programación Orientada a Objetos (POO)

La Programación Orientada a Objetos (POO) es un paradigma que organiza el software en torno a objetos en lugar de en torno a funciones y datos separados. Frente a la programación estructurada tradicional, que separa los datos de los procedimientos y busca esencialmente el procesamiento de unos datos de entrada para obtener otros de salida, la POO une datos y comportamiento en una misma entidad. Esa es la diferencia esencial entre ambos enfoques: la programación estructurada separa datos y procedimientos, mientras que la POO los agrupa en objetos.

El objeto: identidad, estado y comportamiento

Un objeto es la abstracción de un dato y su comportamiento. Todo objeto queda definido por tres componentes:

• Identidad: propiedad que diferencia al objeto de todos los demás, incluso de otros con el mismo estado. Es lo que lo hace único.

• Estado: los valores concretos de sus datos en un momento dado.

• Comportamiento: las operaciones que puede realizar.

Así, la definición de un objeto se compone de identidad, comportamiento y estado. Los datos internos del objeto se denominan atributos (las propiedades del objeto), y las operaciones se implementan mediante métodos.

Un método es un algoritmo asociado a un objeto cuya ejecución se desencadena tras la recepción de un "mensaje"; dicho de otro modo, es una función que se ejecuta cuando se invoca sobre un objeto. Un caso particular es el constructor, un método especial que define el proceso de creación de un objeto. El acto de crear un objeto concreto a partir de su plantilla se llama instanciación, cuyo propósito es crear nuevos objetos fácilmente.

La clase

Una clase es una plantilla o molde en la que se definen los atributos y métodos predeterminados de un tipo de objeto. Los objetos son instancias de una clase.

Pilares y características de la POO

• Abstracción: proceso que consiste en reconocer y enfocarse en las características importantes de una situación u objeto y filtrar o ignorar los detalles no esenciales. Permite al diseñador centrarse en los detalles esenciales de un componente sin preocuparse por los de nivel inferior, y seleccionar características relevantes para definir nuevos tipos de entidades.

• Encapsulamiento (encapsulación): proceso que oculta los detalles internos de un objeto del mundo exterior, actuando como una barrera protectora. Permite además reunir todos los elementos que pertenecen a una misma entidad al mismo nivel de abstracción. Combinado con la ocultación y la abstracción, mejora la legibilidad del código y facilita el trabajo en grupo.

• Modularidad: permite dividir o subdividir una aplicación en partes más pequeñas, cada una lo más independiente posible. Al implementarla deben seguirse dos conceptos clave: bajo acoplamiento y alta cohesión.

• Herencia: una clase (subclase o clase derivada) puede heredar atributos y métodos de otra (superclase o clase padre).

• Polimorfismo, sobrecarga y ocultación de información completan el modelo.

Un dato importante: la recursividad NO es una característica del paradigma orientado a objetos (es una técnica algorítmica general).

Niveles de acceso (ocultación de información)

Los atributos y métodos pueden declararse con distintos niveles de visibilidad:

• public: accesible desde cualquier parte.

• private: solo accesible desde la propia clase. Su fin es evitar que el usuario de la clase pueda cambiar su estado de manera imprevista e incontrolada.

• protected (protegido): se usa cuando una clase tendrá clases que deriven de ella (herencia) y las clases hijas necesitan acceder a los atributos de la clase padre.

El nivel delegate NO existe como nivel de acceso.

Para que un lenguaje sea considerado orientado a objetos debe soportar objetos, que estos tengan un tipo o clase asociado, y que dichas clases puedan heredar atributos de una clase superior o superclase.

Corrientes de la POO

Historia

Simula es considerado el primer lenguaje que posee las características principales de un lenguaje orientado a objetos. No obstante, el lenguaje que más influyó en el desarrollo de la teoría de la POO fue Smalltalk, considerado el ejemplo canónico con el que se ha desarrollado gran parte de dicha teoría.

Lenguajes orientados a objetos

• Puros / principalmente OO: Java, C#, Python, Ruby, Smalltalk, Swift, PHP.

• Los dos más utilizados actualmente: C# y Java.

• Enfocados a desarrollo web: Python, PHP y Ruby.

• ABAP: empleado principalmente en sistemas empresariales (SAP).

• ADA: utilizado en aplicaciones de defensa y líneas aéreas.

• C: NO es orientado a objetos.

• C++: originalmente no orientado a objetos, pero fue extendido para soportar el paradigma.

Ventajas

• Facilidad de mantenimiento y modificación de los objetos existentes.

• Gestión de errores: se sabe exactamente dónde mirar cuando se produce un error.

• Trabajo en grupo más sencillo gracias al encapsulamiento.

• Su estructura modular no revela el mecanismo detrás del diseño (ocultación).

Inconvenientes

• No hay una forma única de resolver los problemas, lo que requiere documentación amplia para determinar la solución planteada.

• Limitaciones del programador: si desconoce las características del paradigma, puede seguir usando el paradigma estructurado en lugar del orientado a objetos.

• Curva de aprendizaje: exige un cambio en la forma de pensar de la programación tradicional a la orientada a objetos.

• Velocidad: la ejecución de programas orientados a objetos suele ser más lenta.

Fuentes

• Wikipedia (EN) — Object-oriented programming: https://en.wikipedia.org/wiki/Object-oriented_programming

• Carnegie Mellon University — OO History: Simula and Smalltalk (15-214): https://www.cs.cmu.edu/~charlie/courses/15-214/2014-fall/slides/25-history-oo.pdf

• The Go Programming Language — Methods (receivers value/pointer): https://go.dev/tour/methods/8

• MDN Web Docs — Inheritance and the prototype chain (JavaScript): https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Inheritance_and_the_prototype_chain

Herencia, polimorfismo y sobrecarga

La programación orientada a objetos (POO) modela el software como un conjunto de objetos (instancias de clases) que colaboran mediante el intercambio de mensajes. Sobre este modelo, tres mecanismos vertebran la reutilización y la flexibilidad del código: la herencia, el polimorfismo y la sobrecarga. Este sub-tema los aborda con el rigor exigible en la oposición TAI.

Herencia

La herencia es la capacidad de un objeto (o clase) de adquirir las propiedades y los métodos de otro objeto (o clase). Dicho de otro modo, es la facilidad de heredar los atributos y las operaciones de una clase padre (o superclase, clase base) en una clase hija (o subclase, clase derivada). El proceso por el cual una clase hereda los métodos y propiedades de otra recibe precisamente el nombre de herencia.

Su valor principal es la reutilización de código: permite crear una única clase y compartir muchas de sus propiedades con múltiples subclases, sin tener que volver a implementar el comportamiento común. La subclase hereda las propiedades, el comportamiento y las relaciones de la superclase y, a la vez, puede añadir sus propias propiedades, relaciones y comportamiento, o modificar los heredados.

En UML esta relación se modela como generalización/especialización entre clases:

• Generalización: proceso ascendente por el que, a partir de clases concretas, se abstraen sus características comunes en una superclase más general.

• Especialización: proceso inverso a la generalización, por el cual se definen nuevas clases (más específicas) a partir de otras ya existentes. Una relación de generalización implica que la subclase hereda todo lo de la superclase y puede extenderlo.

Herencia simple frente a herencia múltiple

• Herencia simple: una entidad hijo tiene una sola entidad padre directa. Es el modelo de lenguajes como Java, donde toda clase tiene una y solo una superclase directa.

• Herencia múltiple: una clase hereda de dos o más superclases directas.

Un error frecuente que conviene desmentir es afirmar que "la herencia entre dos clases puede ser múltiple y todo lenguaje orientado a objetos debe ofrecer esta posibilidad": esta afirmación es INCORRECTA. La herencia múltiple no es obligatoria y muchos lenguajes orientados a objetos (Java, C#) no la ofrecen entre clases —por los conflictos que genera (p. ej. el "problema del diamante")—, resolviéndose mediante interfaces. Por tanto, en una relación de herencia simple una entidad hija puede tener una única entidad padre.

Polimorfismo

El polimorfismo es la característica que permite que comportamientos diferentes, asociados a objetos distintos, compartan el mismo nombre. Formulado con precisión, es la propiedad por la que es posible enviar mensajes sintácticamente iguales a objetos de tipos distintos, de modo que un mismo mensaje puede originar conductas completamente diferentes al ser recibido por diferentes objetos.

Un objeto polimórfico es, por tanto, una entidad que puede comportarse de diferentes maneras según el contexto, permitiendo que una misma referencia o interfaz represente objetos de distintas clases. Una operación cuyo nombre es el mismo en diferentes clases pero cuya ejecución difiere en cada una de ellas es una manifestación de polimorfismo.

En lenguajes como Java, el mecanismo que lo sustenta es la invocación de método virtual (virtual method invocation): la máquina virtual llama al método correspondiente al objeto real referenciado, no al método definido por el tipo de la variable. Así, tres variables declaradas como el mismo tipo base pero instanciadas con subclases distintas responden de forma específica según su clase a un idéntico mensaje.

Sobrescritura (overriding)

Estrechamente ligada al polimorfismo está la sobrescritura o overriding: es el concepto que describe la capacidad de una subclase para modificar o ampliar el comportamiento heredado de su superclase. Se produce cuando, en herencia simple, una subclase define un método con la misma firma (mismo nombre y misma lista de parámetros) que un método de su superclase, especializando su comportamiento. No debe confundirse con la sobrecarga.

Sobrecarga (overloading)

La sobrecarga permite definir dos o más métodos con el mismo nombre pero con parámetros diferentes en cantidad y/o tipo; es decir, crear múltiples funciones/métodos que se llaman igual pero con funcionalidad diferente. Los métodos sobrecargados deben distinguirse o bien en el número de parámetros o bien en el tipo de los parámetros.

El compilador selecciona qué versión de la función sobrecargada emplear en función de los argumentos: se resuelve por el número, el tipo y el orden de los parámetros (la lista de parámetros o firma). Un punto crítico: el tipo de retorno NO diferencia métodos sobrecargados; no se pueden declarar dos métodos con la misma firma aunque cambie el valor devuelto.

Clases abstractas

Una clase abstracta no se instancia directamente; su propósito principal es definir un esqueleto de funcionalidad para las clases derivadas. Declara operaciones (a menudo métodos abstractos sin implementación) que las subclases están obligadas a concretar, imponiendo un contrato común y favoreciendo el uso polimórfico a través del tipo base.

Ventajas e inconvenientes

• Ventajas: mayor reutilización de código (herencia), extensibilidad y bajo acoplamiento frente al código cliente (polimorfismo), y legibilidad y flexibilidad de las interfaces (sobrecarga).

• Inconvenientes: un abuso de la herencia genera jerarquías rígidas y fuerte acoplamiento entre padre e hijo; la herencia múltiple introduce ambigüedades; y el exceso de sobrecargas puede dificultar la comprensión. Por ello el diseño moderno tiende a "componer antes que heredar".

Fuentes

• Oracle — The Java Tutorials: Inheritance (Subclasses and Superclasses): https://docs.oracle.com/javase/tutorial/java/IandI/subclasses.html

• Oracle — The Java Tutorials: Polymorphism: https://docs.oracle.com/javase/tutorial/java/IandI/polymorphism.html

• Oracle — The Java Tutorials: Defining Methods (Overloading Methods): https://docs.oracle.com/javase/tutorial/java/javaOO/methods.html

• Object Management Group (OMG) — Unified Modeling Language (UML) Specification (Generalization/Specialization): https://www.omg.org/spec/UML/

Patrones de diseño

Un patrón de diseño es una solución probada y reutilizable a un problema recurrente en el diseño de software orientado a objetos. Los patrones no son código concreto, sino plantillas que describen cómo estructurar clases y objetos para lograr sistemas flexibles, mantenibles y con bajo acoplamiento. La referencia canónica es el libro Design Patterns: Elements of Reusable Object-Oriented Software (1994), escrito por Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides, conocidos como la GoF (Gang of Four). Este catálogo define 23 patrones organizados en tres categorías (y solo tres): de creación, estructurales y de comportamiento. Términos como "de iteracción", "de administración" o "de interacción" no son categorías válidas de la clasificación GoF.

Patrones de creación (creational)

Su objetivo es inicializar y configurar clases y objetos, abstrayendo el proceso de instanciación para que el cliente no dependa de cómo se crean los objetos. Son cinco: Abstract Factory, Builder, Factory Method, Prototype y Singleton. Una afirmación incorrecta sobre ellos es decir que "definen la forma en que los objetos interactúan entre sí": eso corresponde a los patrones de comportamiento, no a los de creación.

Patrones estructurales (structural)

Su propósito es desacoplar la interfaz y la implementación de clases y objetos, componiendo objetos para formar estructuras mayores. Son siete: Adapter, Bridge, Composite, Decorator, Facade, Flyweight y Proxy. Conviene recordar que Adapter NO es un patrón de creación, sino estructural.

Patrones de comportamiento (behavioral)

Su objetivo es gestionar las interacciones dinámicas entre sociedades de clases y objetos, es decir, cómo se comunican y reparten responsabilidades. Son once: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method y Visitor.

Principio Abierto-Cerrado (OCP)

Enunciado por Bertrand Meyer, el Principio Abierto-Cerrado establece que las entidades de software deben estar abiertas a la extensión pero cerradas a la modificación. Como criterio práctico de diseño, si al introducir un cambio este impacta a varios módulos de la aplicación, es señal de que la aplicación no está bien diseñada. Los patrones de diseño ayudan a cumplir este principio.

Arquitectura Modelo-Vista-Controlador (MVC)

MVC es un patrón arquitectónico que separa la interfaz de usuario de la lógica de negocio subyacente, dividiendo la aplicación en tres componentes:

• Modelo: gestiona los datos y la lógica de negocio del sistema; es el modelo (no el controlador) quien gestiona todos los accesos a la información con la que opera el sistema (base de datos, API, etc.).

• Vista: presenta la información al usuario (renderiza el modelo). La vista NO recibe las peticiones ni solicita los datos al modelo; su papel es la presentación.

• Controlador: recibe las peticiones del usuario, interactúa con el modelo y selecciona la vista a mostrar. Es el punto de entrada que coordina modelo y vista.

Por tanto, es falso afirmar que "el controlador gestiona todos los accesos a la información" (eso es responsabilidad del modelo) o que "la vista recibe las peticiones y solicita los datos al modelo" (eso corresponde al controlador). Esta separación de responsabilidades mejora la organización, el mantenimiento y la escalabilidad del código.

Fuentes

• Gamma, Helm, Johnson, Vlissides (Gang of Four), Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994 (catálogo de 23 patrones y su clasificación).

• Refactoring.Guru — Catálogo de patrones de diseño: https://refactoring.guru/es/design-patterns/catalog

• Wikipedia — Model–view–controller: https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

• Microsoft Learn — Overview of ASP.NET Core MVC: https://learn.microsoft.com/en-us/aspnet/core/mvc/overview

• MDN Web Docs — MVC (Glossary): https://developer.mozilla.org/en-US/docs/Glossary/MVC

Lenguaje Unificado de Modelado (UML)

UML son las siglas de Unified Modeling Language (Lenguaje Unificado de Modelado). Es un lenguaje gráfico estandarizado por el Object Management Group (OMG) —cuya versión actual de referencia es UML 2.5 / 2.5.1— para visualizar, especificar, construir y documentar los artefactos de un sistema software. UML no es un lenguaje de programación orientado a objetos, sino un lenguaje de modelado; sin embargo, existen herramientas CASE que permiten generar código en diversos lenguajes a partir de sus diagramas (ingeniería directa) y también obtener diagramas desde el código (ingeniería inversa). Por ello es incorrecto afirmar que «UML es un lenguaje de programación orientado a objetos que guarda relación directa con el análisis y el diseño orientados a objetos»: guarda relación con el análisis y diseño OO, pero no es un lenguaje de programación.

UML permite modelar tanto los aspectos estáticos (estructura) como los aspectos dinámicos (comportamiento) de un sistema, y es aplicable en las distintas fases del ciclo de vida del desarrollo. Por tanto, es falso decir que UML «muestra únicamente el modelado estático»: cubre estructura y comportamiento.

Bloques de construcción y mecanismos comunes

UML se compone de bloques de construcción (elementos, relaciones y diagramas), reglas y mecanismos comunes. Entre los mecanismos comunes destacan los mecanismos de extensibilidad (o de extensión), que permiten adaptar el lenguaje de forma controlada a las necesidades de un proyecto concreto y a nuevas tecnologías de software. UML proporciona tres mecanismos de extensión:

• Estereotipos (stereotypes): amplían el vocabulario de UML permitiendo crear nuevos tipos de bloques de construcción derivados de los existentes (p. ej. «interface», «control»). Se representan entre comillas angulares « ».

• Valores etiquetados (tagged values): extienden las propiedades de un elemento, añadiendo nueva información (metadatos) al modelo.

• Restricciones (constraints): añaden nuevas reglas o modifican las existentes sobre un bloque de construcción, por ejemplo imponiendo reglas de orden a una clase. Una restricción especifica condiciones que deben cumplirse.

Elementos como los adornos (adornments) NO son mecanismos de extensión, sino detalles gráficos añadidos a la notación básica.

Conceptos de orientación a objetos en UML

• Clase: es el componente básico para modelar objetos; representa una entidad con atributos (estado) y operaciones/métodos (comportamiento). En un diagrama de clases se representa con un rectángulo dividido en tres compartimentos por líneas horizontales (nombre, atributos y operaciones). Es incorrecto/falso afirmar que una clase «se representa por un círculo dividido en tres zonas».

• Herencia (generalización): es el mecanismo para crear nuevas clases a partir de una ya existente, heredando sus atributos y operaciones. En el diagrama de clases la herencia/generalización se representa mediante una línea sólida con una punta de flecha triangular sin rellenar (hueca) que apunta a la superclase.

Un tipo de relación entre elementos estructurales es la asociación (y sus variantes: agregación, composición, dependencia, generalización). No existe en UML una asociación denominada «dispersión»: por eso esa afirmación NO se corresponde con UML.

Clasificación de los diagramas UML

Los diagramas UML se agrupan en dos grandes familias —diagramas de estructura y diagramas de comportamiento—, y dentro del comportamiento se distinguen los diagramas de interacción. De ahí que suelan citarse tres categorías: estructura, comportamiento e interacción.

Diagramas de estructura (aspectos estáticos)

Representan la relación estructural de los elementos del sistema. En UML 2.5 son: Clases, Objetos, Paquetes, Componentes, Despliegue, Estructura compuesta y Perfil. Una opción formada exclusivamente por diagramas de estructura sería, por ejemplo: Diagrama de Clases, Diagrama de Objetos, Diagrama de Paquetes, Diagrama de Despliegue y Diagrama de Perfil.

• Diagrama de clases: muestra la estructura estática del sistema: sus clases, atributos, operaciones y objetos, y las relaciones entre ellas.

• Diagrama de objetos: instancias concretas del diagrama de clases en un momento dado.

• Diagrama de componentes: muestra la relación estructural de los elementos (componentes) del software.

• Diagrama de despliegue: arquitectura de ejecución (nodos, artefactos).

• Diagrama de paquetes y de perfil (este último define estereotipos, valores etiquetados y restricciones).

El Diagrama de Casos de Uso NO es un diagrama de estructura, sino de comportamiento.

Diagramas de comportamiento (aspectos dinámicos)

Su propósito es representar los aspectos dinámicos del sistema, enfocándose en el comportamiento y la interacción de sus elementos. Son:

• Diagrama de casos de uso: ilustra cómo se relacionan las funcionalidades del sistema con sus actores (controladores) internos/externos. Relaciones típicas: inclusión («include») —un caso de uso base incorpora explícitamente el comportamiento de otro en algún punto de su secuencia— y extensión («extend»). En la extensión, la flecha apunta al caso de uso base (extendido): si A es el caso extendido y B lo extiende, A es completo por sí solo y puede opcionalmente incluir el comportamiento de B.

• Diagrama de actividades: representa flujos de trabajo de negocio u operativos y la lógica de operaciones complejas (reglas de negocio, casos de uso) mediante actividades y decisiones.

• Diagrama de máquina de estados (diagrama de estados): documenta los distintos estados por los que pasa una clase/objeto y los eventos que provocan las transiciones; describe objetos que se comportan de forma distinta según su estado actual.

Diagramas de interacción (subtipo de comportamiento)

Describen en detalle un escenario concreto de un caso de uso (así los define también Métrica v3), mostrando la interacción entre objetos:

• Diagrama de secuencia: representa la interacción entre objetos en un escenario específico, haciendo hincapié en la ordenación temporal de los mensajes. Su eje vertical representa el tiempo. Sus elementos son objetos, líneas de vida, mensajes y activaciones; las interfaces NO son un elemento propio del diagrama de secuencia.

• Diagrama de comunicación (antes colaboración): hace hincapié en los mensajes que se intercambian entre objetos y su organización estructural. Es falso que muestre la arquitectura física del sistema.

Fuentes

• OMG — Unified Modeling Language (UML) Specification, versión 2.5.1: https://www.omg.org/spec/UML/2.5.1/About-UML

• OMG — UML 2.5 Specification: https://www.omg.org/spec/UML/2.5/

• UML Diagrams — Clasificación de diagramas UML 2.x (estructura/comportamiento/interacción): https://www.uml-diagrams.org/

• Métrica v3 (Ministerio de Hacienda / administracionelectronica.gob.es) — Técnica «Diagrama de Interacción»: https://manuel.cillero.es/doc/metodologia/metrica-3/tecnicas/diagrama-de-interaccion/

• Métrica Versión 3 (documento oficial): https://www.preparatic.org/material/20100918/Metrica_v3.pdf