Tema 18. Diseño y programación orientada a objetos. Elementos y componentes software: objetos, clases, herencia, métodos, sobrecarga. Ventajas e inconvenientes. Patrones de diseño y lenguaje de modelado unificado (UML).

1. Diseño y programación orientada a objetos

1. Diseño y programación orientada a objetos

🎯 Idea clave

• El diseño y la programación orientada a objetos constituyen un enfoque integral de análisis, diseño y construcción de software basado en entidades con responsabilidades definidas.
• La idea central organiza los sistemas como colaboración entre objetos, abandonando el modelo de secuencia lineal de instrucciones o funciones aisladas.
• Cada objeto representa una unidad software con identidad propia, datos internos y operaciones disponibles mediante una interfaz definida.
• Este paradigma trasciende la mera codificación para abarcar el modo de pensar el dominio del problema y descomponer responsabilidades.
• En la fase de diseño se reconocen los conceptos relevantes del dominio y se transforman en abstracciones software estructuradas.
• En programación se materializan estas abstracciones mediante clases, objetos, métodos, atributos e interfaces según las características del lenguaje utilizado.

📚 Desarrollo

Enfoque metodológico. El diseño y la programación orientada a objetos constituyen un enfoque sistemático de análisis, diseño y construcción de software que se fundamenta en la identificación de entidades relevantes, junto con sus responsabilidades específicas, su estado y su comportamiento. Este método permite abordar la complejidad de los sistemas mediante la división en unidades manejables con responsabilidades bien delimitadas.

Organización por colaboración. La idea central de este paradigma consiste en organizar un sistema como una colaboración entre objetos, en lugar de concebirlo únicamente como una secuencia de instrucciones o funciones aisladas. Cada objeto representa una unidad independiente que posee identidad propia, datos internos y operaciones disponibles a través de una interfaz claramente definida.

Trascendencia técnica. La orientación a objetos no se circunscribe a una mera técnica de codificación, sino que abarca el modo de pensar el dominio del problema. Implica descomponer responsabilidades de manera lógica, definir clases apropiadas, establecer relaciones significativas entre las distintas entidades y controlar las dependencias entre componentes de forma explícita y estructurada.

Fase de análisis y diseño. En la etapa de diseño orientado a objetos, el objetivo principal radica en reconocer los conceptos relevantes del dominio problemático y transformarlos progresivamente en abstracciones software concretas. Este proceso requiere identificar con precisión qué entidades son significativas para el sistema y cómo deben comportarse para cumplir efectivamente los requisitos funcionales establecidos.

Implementación práctica. Durante la fase de programación, las abstracciones diseñadas se materializan mediante la utilización de clases, objetos, métodos, atributos, interfaces, herencia, composición y mecanismos de encapsulación. La implementación concreta depende de las características específicas del lenguaje de programación seleccionado para el desarrollo del sistema.

Caracterización de unidades. Un objeto se define como una entidad software que posee identidad, estado y comportamiento diferenciados. La identidad permite distinguirlo de otros objetos aunque compartan valores idénticos, mientras que el estado se representa mediante atributos y el comportamiento mediante métodos que garantizan la coherencia interna de la unidad frente a operaciones externas.

🧩 Elementos esenciales

• Análisis orientado a objetos: fase inicial donde se identifican entidades relevantes del dominio junto con sus responsabilidades, estado y comportamiento específicos.
• Diseño orientado a objetos: proceso de transformar los conceptos identificados del dominio en abstracciones software estructuradas y relacionadas entre sí.
• Programación orientada a objetos: implementación práctica de las abstracciones diseñadas mediante construcciones concretas del lenguaje de programación seleccionado.
• Colaboración entre objetos: forma de organizar el sistema donde las unidades software interactúan mediante mensajes y operaciones definidas en sus interfaces.
• Identidad de objetos: propiedad fundamental que distingue un objeto de otro de manera única e inmutable, independientemente de sus valores de estado interno.
• Encapsulación: mecanismo que protege el estado interno del objeto y expone únicamente una interfaz controlada de operaciones permitidas.
• Descomposición de responsabilidades: técnica de dividir el sistema en unidades con tareas específicas y delimitadas para reducir la complejidad global.
• Control de dependencias: gestión explícita de las relaciones entre componentes para mantener el sistema modular, mantenible y evolutivo.

🧠 Recuerda

• El diseño y la programación orientada a objetos organizan el software como colaboración entre objetos autónomos, no como flujo secuencial de instrucciones.
• Un objeto es una unidad que combina estado, comportamiento e identidad de manera inseparable.
• Este enfoque abarca el análisis del dominio, el diseño de abstracciones y la implementación práctica en código.
• La identidad permite distinguir objetos aunque contengan exactamente los mismos valores de estado.
• En diseño se transforman los conceptos del dominio en entidades software con responsabilidades definidas.
• La encapsulación protege el estado interno y expone únicamente operaciones controladas mediante interfaces.
• El objetivo principal es descomponer responsabilidades y controlar dependencias entre componentes.
• La orientación a objetos es un modo de pensar el dominio, no solo una sintaxis de programación.
• Las abstracciones de diseño se implementan mediante clases, métodos, atributos e interfaces según el lenguaje.
• Un buen diseño busca alta cohesión interna en cada objeto y bajo acoplamiento entre objetos distintos.

2. Elementos y componentes software: objetos, clases, herencia, métodos, sobrecarga

2. Elementos y componentes software: objetos, clases, herencia, métodos, sobrecarga

🎯 Idea clave

• Un objeto es una entidad software con identidad, estado y comportamiento que ofrece operaciones significativas manteniendo coherencia interna.
• Una clase constituye la plantilla que define la estructura y operaciones de sus objetos, existiendo en diseño mientras que los objetos existen en ejecución.
• La herencia modela la relación de especialización IS-A entre clases, pudiendo ser simple o múltiple según el lenguaje de programación.
• La sobrecarga permite definir métodos con idéntico nombre y distinta firma resuelta estáticamente, mientras que la sobrescritura redefine métodos heredados resuelta dinámicamente.
• El encapsulamiento protege el estado interno mediante modificadores de acceso y exposición controlada de la interfaz.
• Los componentes software agrupan clases y recursos bajo una interfaz funcional coherente facilitando la reutilización y el control de dependencias.

📚 Desarrollo

Definición de objeto. Un objeto es una entidad software caracterizada por poseer identidad única, estado representado mediante atributos, y comportamiento expresado a través de métodos. No debe entenderse como una simple bolsa de datos, sino como una unidad que mantiene coherencia interna y ofrece operaciones significativas.

Clase como plantilla. Una clase es la definición o plantilla a partir de la cual se generan objetos, describiendo qué datos contendrán y qué operaciones ofrecerán. La clase existe en el nivel de diseño y código, mientras que el objeto existe en tiempo de ejecución como instancia concreta con valores específicos en sus atributos.

Estado y comportamiento. Los atributos representan la información asociada a un objeto y pueden tener distintos niveles de acceso. Los métodos son las operaciones asociadas a una clase u objeto, pudiendo ser de instancia cuando operan sobre un objeto concreto, o estáticos cuando pertenecen a la clase sin necesitar instancia.

Encapsulación y protección. La encapsulación protege el estado interno mediante una interfaz controlada, utilizando modificadores de acceso como público, privado, protegido o package-private. Exponer atributos sin control debilita la encapsulación, por lo que el estado debe modificarse mediante métodos o propiedades que conserven invariantes.

Mecanismo de herencia. La herencia expresa especialización entre clases modelando la relación IS-A, siendo simple en lenguajes como Java o C# y múltiple en C++ o Python, este último con el conocido problema del diamante. También puede implementarse mediante interfaces para definir contratos o mediante mixins y traits como alternativa intermedia.

Sobrecarga y sobrescritura. La sobrecarga define métodos con el mismo nombre y parámetros distintos, resuelta estáticamente en compilación. La sobrescritura redefine un método heredado manteniendo la misma firma y contrato compatible, resuelta dinámicamente en ejecución permitiendo polimorfismo de subtipo.

Polimorfismo y composición. El polimorfismo permite usar objetos distintos mediante un contrato común, manifestándose como subtipo, paramétrico mediante genéricos, o ad-hoc mediante sobrecarga. La composición construye clases mediante colaboradores, siendo generalmente más flexible que las jerarquías de herencia profundas.

Componentes software. Un componente software agrupa clases y recursos bajo una interfaz funcional coherente, permitiendo construir sistemas a partir de unidades con responsabilidades definidas que organizan el código y controlan dependencias.

🧩 Elementos esenciales

• Objeto: Entidad con identidad única, estado (atributos) y comportamiento (métodos) que mantiene coherencia interna.
• Clase: Plantilla que define estructura y operaciones; existe en diseño frente a la instancia que existe en ejecución.
• Atributos: Representan el estado del objeto con niveles de acceso que determinan su visibilidad y modificabilidad.
• Métodos de instancia: Operan sobre un objeto concreto específico dependiendo del estado del mismo.
• Métodos estáticos: Pertencen a la clase general sin requerir instancia para su invocación.
• Encapsulamiento: Protección del estado interno mediante modificadores de acceso y exposición controlada.
• Herencia: Relación IS-A de especialización entre clases, implementada como simple o múltiple según el lenguaje.
• Sobrecarga (overloading): Definición de múltiples métodos con idéntico nombre y distinta firma resuelta estáticamente.
• Sobrescritura (overriding): Redefinición de método heredado conservando firma y contrato, resuelta dinámicamente.
• Polimorfismo: Capacidad de usar objetos distintos mediante contrato común, incluyendo subtipo, paramétrico y ad-hoc.
• Composición: Construcción de clases mediante colaboradores que suele ofrecer mayor flexibilidad que la herencia profunda.
• Componente software: Agrupación de clases y recursos bajo interfaz funcional coherente que facilita reutilización.

🧠 Recuerda

• Un objeto tiene identidad, estado y comportamiento; no es solo una bolsa de datos.
• Una clase define la estructura y operaciones; el objeto es la instancia concreta en ejecución.
• Los atributos representan estado; los métodos representan comportamiento.
• La encapsulación protege el estado interno mediante una interfaz controlada.
• La herencia expresa especialización entre clases siguiendo la relación IS-A.
• La sobrescritura redefine un método heredado manteniendo la firma y se resuelve dinámicamente.
• La sobrecarga define métodos con el mismo nombre y parámetros distintos, resuelta estáticamente.
• El polimorfismo permite usar objetos distintos mediante un contrato común.
• La composición construye clases mediante colaboradores y suele ser más flexible que herencias profundas.
• Un componente software agrupa clases y recursos bajo una interfaz funcional coherente.

3. Ventajas e inconvenientes

3. Ventajas e inconvenientes

🎯 Idea clave

• La programación orientada a objetos organiza sistemas mediante abstracciones que combinan estado y comportamiento, facilitando la reutilización y el mantenimiento del software.
• La modularidad permite dividir sistemas en componentes con responsabilidades diferenciadas y fronteras claras, mejorando la legibilidad y la localización de errores.
• La capacidad de evolución posibilita incorporar nuevas clases sin alterar el núcleo existente, siguiendo el principio de estar abiertos a la extensión pero cerrados a la modificación.
• La distribución del trabajo en equipos se facilita mediante interfaces que actúan como contratos formales entre desarrolladores.
• El principal riesgo es la sobreingeniería, que genera complejidad innecesaria cuando se aplican abstracciones excesivas a problemas que no las requieren.
• No constituye un paradigma universalmente superior, sino una herramienta adecuada únicamente cuando ayuda a modelar y mantener la complejidad del dominio.

📚 Desarrollo

Organización mediante abstracciones. La programación orientada a objetos permite estructurar sistemas mediante entidades que agrupan datos internos y operaciones disponibles, acercando el modelo computacional a la forma en que se conceptualizan los problemas del mundo real. Este enfoque favorece la encapsulación de detalles y facilita la reutilización de componentes en diferentes contextos.

Ventaja modular. La división del sistema en clases y componentes con responsabilidades diferenciadas permite concentrarse en conceptos específicos sin necesidad de comprender la totalidad del programa. Esta modularidad real mejora la lectura del código, facilita la localización de errores y permite sustituir partes individuales sin afectar al conjunto.

Capacidad evolutiva. Los sistemas bien diseñados pueden incorporar nuevas clases o implementaciones sin alterar el núcleo existente, respondiendo al principio abierto/cerrado. No obstante, diseñar para extensiones hipotéticas puede introducir complejidad especulativa innecesaria cuando estas no responden a cambios plausibles sino a posibilidades imaginarias.

Trabajo colaborativo. La existencia de fronteras claras entre componentes permite que distintos desarrolladores trabajen simultáneamente sobre clases o módulos diferentes. Las interfaces sirven como contratos formales que facilitan la revisión y el mantenimiento, resultando especialmente valiosas en equipos grandes de desarrollo.

Riesgo de sobreingeniería. El principal inconveniente surge cuando se crean jerarquías complejas, interfaces adicionales, fábricas o patrones para resolver problemas que no los requieren. Un diseño con numerosas clases para una operación sencilla puede ser técnicamente orientado a objetos y simultáneamente constituir un mal diseño difícil de leer.

Limitaciones y abusos. La orientación a objetos presenta riesgos cuando se abusa de la herencia, se generan demasiadas clases, se oculta excesivamente el flujo de ejecución o se introducen abstracciones innecesarias. No es un paradigma universalmente superior, sino adecuado únicamente cuando realmente ayuda a modelar y mantener la complejidad del dominio problemático.

🧩 Elementos esenciales

• Modularidad: División del sistema en clases con responsabilidades diferenciadas que facilitan la lectura, el mantenimiento y la sustitución de componentes.
• Encapsulación: Protección del estado interno de los objetos y exposición controlada de operaciones mediante interfaces bien definidas.
• Principio abierto/cerrado: Capacidad de extender funcionalidades mediante nuevas clases sin modificar el código existente del núcleo del sistema.
• Interfaces como contratos: Mecanismos que permiten establecer acuerdos formales entre componentes y facilitar el trabajo paralelo en equipos grandes.
• Sobreingeniería: Tendencia a crear jerarquías, patrones y capas innecesarias para problemas que admitirían soluciones más simples.
• Complejidad especulativa: Diseño excesivo orientado a extensiones hipotéticas no probables que complican el sistema sin aportar valor real.
• Abuso de herencia: Uso excesivo del mecanismo de especialización que puede crear acoplamiento indeseado entre clases padre e hijas.
• Fronteras artificiales: División del trabajo que genera dependencias cruzadas excesivas entre componentes, complicando la coordinación del equipo.

🧠 Recuerda

• La POO organiza el software como colaboración entre objetos, no como simple secuencia de instrucciones o funciones aisladas.
• La modularidad real exige fronteras claras entre componentes; no basta con crear muchas clases sin criterio.
• Las dependencias del sistema deben dirigirse hacia abstracciones, no hacia detalles concretos de implementación.
• La sobreingeniería convierte soluciones simples en sistemas difíciles de leer y mantener.
• No toda clase es necesaria: un diseño con veinte clases para una operación sencilla sigue siendo mal diseño.
• La extensibilidad debe responder a cambios plausibles, no a cualquier posibilidad imaginada.
• Las interfaces permiten distribuir trabajo, pero las dependencias cruzadas excesivas generan conflictos continuos.
• Orientación a objetos no significa llenar el sistema de clases, sino asignar responsabilidades correctamente a las entidades adecuadas.

4. Patrones de diseño y lenguaje de modelado unificado (UML)

4. Patrones de diseño y lenguaje de modelado unificado (UML)

🎯 Idea clave

• Los patrones de diseño son soluciones generales, probadas y nombradas para problemas recurrentes que aparecen en el diseño de software orientado a objetos.
• UML es el lenguaje gráfico estandarizado para visualizar, especificar, construir y documentar sistemas software, surgido de la fusión de los métodos Booch, OOSE y OMT.
• La especificación UML 2.5 distingue catorce tipos de diagramas agrupados en siete estructurales y siete de comportamiento.
• Ambas herramientas son complementarias: los patrones aportan soluciones reutilizables y UML proporciona la notación para representarlas y comunicarlas.
• Un patrón no es una clase concreta ni un fragmento de código copiable, sino una plantilla que debe adaptarse al contexto específico tras comprender el problema.
• UML se emplea con metodologías diversas como RUP o ágiles, y resulta central en arquitecturas dirigidas por modelos como MDA y MDSD.

📚 Desarrollo

Definición de patrón. Un patrón de diseño describe una solución general para una situación que aparece con frecuencia en el desarrollo de software. No se trata de una clase concreta ni de un fragmento de código que se copia sin más, sino de una plantilla que especifica contexto, problema, fuerzas, solución, participantes y consecuencias. Su utilidad radica en reconocer estructuras de colaboración entre clases u objetos que resuelven el problema planteado.

Naturaleza del patrón. Aplicar un patrón exige entender genuinamente el problema que se intenta resolver; usarlo por moda o sin necesidad concreta introduce complejidad accidental en el sistema. El patrón facilita la reutilización de soluciones probadas, pero siempre requiere una adaptación razonada al dominio particular. Describe relaciones y responsabilidades entre objetos que pueden trasladarse a múltiples implementaciones.

Origen de UML. El Lenguaje Unificado de Modelado (UML) es un estándar gráfico mantenido por el OMG desde 1997, con versión vigente 2.5.1 adoptada en 2017 y reconocida por la norma ISO/IEC 19505. Surgió de la unificación de los métodos de análisis y diseño orientados a objetos más influyentes de los años noventa: el método Booch, OOSE y OMT. Su propósito es ofrecer una notación compartida para comunicar el diseño entre los miembros del equipo.

Tipología de diagramas. UML 2.5 define catorce tipos de diagramas divididos en dos categorías principales. Los siete diagramas estructurales representan aspectos estáticos del sistema: clases, objetos, componentes, despliegue, paquetes, estructura compuesta y perfil. Los siete diagramas de comportamiento capturan aspectos dinámicos: casos de uso, actividades, estados, secuencia, comunicación, descripción general de interacciones y temporización.

Diagramas para diseño. En el contexto específico del diseño orientado a objetos, resultan particularmente útiles para documentar decisiones el diagrama de clases, el de secuencia, el de estados y el de casos de uso. El diagrama de clases es, sin discusión, el más utilizado, pues representa las clases con sus atributos y métodos, así como las relaciones entre ellas: asociación, agregación, composición, herencia, dependencia y realización.

Elementos comunes. UML incorpora mecanismos transversales que enriquecen los modelos. Las notas son anotaciones textuales aclaratorias. Las restricciones expresan condiciones que deben cumplirse, formulables en lenguaje natural o en OCL (Object Constraint Language), un lenguaje formal definido por el OMG. Los estereotipos, escritos entre dobles paréntesis angulares como <<entity>> o <<interface>>, categorizan elementos para añadir semántica específica del dominio.

Extensibilidad y herramientas. Los estereotipos, los valores etiquetados y las restricciones permiten extender UML sin alterar el metamodelo subyacente, adaptándolo a dominios concretos. Existen herramientas comerciales como Enterprise Architect, Visual Paradigm o MagicDraw, así como opciones libres como PlantUML, Diagrams.net o StarUML, que soportan la tendencia de "diagrams as code" para integrar los modelos con sistemas de control de versiones.

Complementariedad práctica. Patrones de diseño y UML son herramientas que se potencian mutuamente. Mientras los patrones ofrecen soluciones reutilizables a problemas conocidos, UML proporciona el vocabulario gráfico para representar esas soluciones, comunicar decisiones de diseño, reducir ambigüedades y razonar sobre el software antes de su implementación. UML se emplea con metodologías diversas y convive con alternativas específicas como C4, BPMN, ArchiMate o SysML.

🧩 Elementos esenciales

• Patrón de diseño: Solución general probada que describe contexto, problema, fuerzas, solución, participantes y consecuencias para problemas recurrentes de diseño.
• UML: Lenguaje gráfico estandarizado (OMG desde 1997, ISO/IEC 19505, versión 2.5.1 de 2017) para visualizar, especificar, construir y documentar sistemas software.
• Diagramas estructurales: Siete tipos (clases, objetos, componentes, despliegue, paquetes, estructura compuesta, perfil) que representan la arquitectura estática del sistema.
• Diagramas de comportamiento: Siete tipos (casos de uso, actividades, estados, secuencia, comunicación, descripción general de interacciones, temporización) que modelan la dinámica del sistema.
• Diagrama de clases: El más utilizado; muestra clases con atributos, métodos y relaciones (asociación, agregación, composición, herencia, dependencia, realización).
• Estereotipos: Mecanismo de extensión mediante etiquetas entre dobles paréntesis angulares que añaden semántica específica sin modificar el metamodelo.
• OCL: Object Constraint Language, lenguaje formal del OMG para expresar restricciones precisas sobre elementos del modelo.
• Complementariedad: Los patrones aportan soluciones reutilizables y UML la notación para representarlas; ambos facilitan la comunicación y reducen ambigüedades en el diseño.

🧠 Recuerda

• Un patrón no es código copiable sin adaptación, sino una plantilla que requiere comprensión del problema.
• UML nació de la fusión de los métodos Booch, OOSE y OMT.
• La versión vigente es UML 2.5.1 (2017), estandarizada por ISO/IEC 19505.
• UML define 14 diagramas: 7 estructurales y 7 de comportamiento.
• El diagrama de clases es el más frecuente en el diseño orientado a objetos.
• Los estereotipos permiten adaptar UML a dominios específicos sin alterar su metamodelo.
• Aplicar patrones innecesariamente introduce complejidad accidental en el sistema.
• Las restricciones en UML pueden expresarse en lenguaje natural o mediante OCL.
• UML se utiliza tanto con metodologías tradicionales como ágiles, y es central en MDA.
• Existen alternativas como C4, BPMN, ArchiMate o SysML para nichos específicos.