Clases, atributos, métodos y visibilidad

La programación orientada a objetos (POO) se basa en dos conceptos fundamentales: clases y objetos.
Para comprender cómo se construyen aplicaciones modernas —ya sea en Java, Kotlin, Python o cualquier otro lenguaje orientado a objetos— es imprescindible entender estos conceptos con claridad.

¿Qué es un objeto?

Un objeto es una entidad concreta que existe durante la ejecución de un programa. Representa algo del mundo real o conceptual y dispone de:

• Estado → Representado por los atributos.
• Comportamiento → Representado por los métodos.
• Identidad → Cada objeto es único, incluso si comparte atributos con otros.

Por ejemplo:

• Cada libro real con su título, ISBN y editorial es un objeto.
• Cada cuenta bancaria de un cliente es un objeto diferente, aunque pertenezcan a la misma clase.

¿Qué es una clase?

Una clase es un molde, plantilla o plano a partir del cual se crean objetos.
Define:

• Qué atributos tendrá cada objeto de esa clase.
• Qué métodos podrán ejecutar.

Ejemplos de clases: Libro, Cuenta, Usuario, Coche, Factura, etc.

Atributos: el estado de los objetos

Los atributos son las propiedades o características que tiene una clase.
Todos los objetos de la clase poseen los mismos atributos, pero con valores diferentes.

Ejemplo: Clase Libro

Podría tener los atributos:

• codigo
• ISBN
• titulo
• editorial
• prestado (para indicar si el libro está prestado o no)

Cada atributo debe especificar:

• Nombre
• Tipo de dato (int, String, boolean…)
• Modificador de acceso
• Opcionalmente: valor por defecto

Ejemplo: Clase Cuenta

• numero: identificador de la cuenta
• saldo: cantidad de dinero disponible

Métodos: el comportamiento de los objetos

Los métodos son acciones que pueden realizar los objetos de una clase. Representan su funcionalidad.

Ejemplo: Métodos de Libro

• prestar()
• devolver()

Estos métodos podrían devolver un boolean indicando si la operación se realizó correctamente (por ejemplo, no se puede prestar un libro ya prestado).

Ejemplo: Métodos de Cuenta

• ingresarDinero(importe)
• extraerDinero(importe)

Ambos reciben un parámetro llamado importe, de tipo numérico (float, double…), que indica cuánto se ingresa o se extrae.

Representación mediante UML: Diagramas de Clases

En UML, una clase se representa con un rectángulo dividido en tres secciones:

1. Nombre de la clase
2. Atributos
3. Métodos

Inicialmente puede bastar con poner solo nombres, pero conforme avanza el diseño se añaden:

• Modificadores de acceso
• Tipos de datos
• Tipos de retorno
• Parámetros con su tipo

Modificadores de acceso en UML

Indican desde qué lugares es accesible un atributo o un método.

Modificador	Símbolo UML	Significado
private	-	Solo accesible por la propia clase
public	+	Accesible desde cualquier clase
protected	#	Accesible por la clase y sus subclases
package	~	Accesible por clases del mismo paquete

Buenas prácticas habituales:

• Los atributos suelen ser private.
• Los métodos suelen ser public.
• Algunos métodos internos pueden ser privados (private) si solo son útiles dentro de la clase.

Tipos de datos más usados en UML

Tipos básicos del propio UML:

• int → enteros
• String → cadenas de caracteres
• boolean → valores verdadero o falso

Tipos típicos del estilo Java/Kotlin:

• float / double → números con decimales
• char → un único carácter
• Date, Time, DateTime → información temporal

Sintaxis UML para especificar atributos y métodos

Atributos

modificador nombreAtributo: tipoDato

Ejemplo:

-int codigo: int

Métodos

modificador nombreMetodo(parametro: tipoDato, ...) : tipoDevuelto

Ejemplo:

+prestar() : boolean
+ingresarDinero(importe: float)

Diagramas completos

Clase LibroClase Cuenta

classDiagram
    class Libro {
        -int codigo
        -String ISBN
        -String titulo
        -String editorial
        -boolean prestado

        +boolean prestar()
        +boolean devolver()
    }

classDiagram
    class Cuenta {
        -String numero
        -float saldo

        +ingresarDinero(importe: float)
        +extraerDinero(importe: float)
    }

Actividades

Recomendación

Se recomienda el uso de la plataforma draw.io, aunque es posible hacerlos con otras soluciones.

• AC405 (RA5 / / IC1 / 1p). magina que estás desarrollando un pequeño sistema para gestionar los préstamos de una biblioteca municipal. A partir de una breve descripción del funcionamiento real (los usuarios pueden registrarse, pedir libros prestados, devolverlos y consultar su historial), identifica claramente cuáles serían las clases principales del sistema, los objetos que podrán instanciarse a partir de cada una de esas clases y las características comunes que justifican que cada clase exista.

  A continuación, describe en un texto bien argumentado qué atributos crees que deberían incluirse en cada clase y justifica el tipo de dato elegido para cada uno de ellos.

  Finalmente, explica qué métodos necesitaría cada clase para representar su comportamiento de forma correcta dentro del programa y razona por qué esos métodos deben ser públicos o privados según el caso.

• AC406 (RA5 / / IC1 / 1p). Supón que una academia quiere registrar la información de los cursos que ofrece y ha decidido crear un sistema informático sencillo. Redacta una propuesta completa para la clase Curso, explicando paso a paso cómo definirías sus atributos, sus métodos y su visibilidad. A partir de un curso típico (por ejemplo, “Programación en Java, 40 horas, modalidad presencial, docente asignado y número máximo de alumnos”), desarrolla un texto en el que especifiques qué atributos existirían, qué tipo de dato debería tener cada uno y por qué.

  Después, redacta qué métodos serían necesarios para gestionar ese curso: matricular alumnos, desmatricularlos, modificar la información del curso y consultar su estado. Describe también qué parámetros deberían recibir esos métodos y qué tipo de valor deberían devolver.

  Termina explicando cómo representarías esta clase mediante un diagrama UML y qué información incluirías o dejarías fuera según la fase de desarrollo del proyecto.

• AC407 (RA5 / / IC1 / 1p). Observa mentalmente el diagrama UML de una clase CuentaBancaria que contiene los atributos numero, titular, saldo y fechaCreacion, así como los métodos ingresar(), retirar() y consultarSaldo(). Imagina que este diagrama te lo han entregado en el contexto de un proyecto real, pero el cliente ha pedido que el sistema permita gestionar también cuentas que generan intereses mensuales, cuentas que pueden congelarse temporalmente y cuentas que admiten varios titulares.

  A partir de esta nueva situación, redacta un texto explicando qué modificaciones realizarías en el diagrama original, qué nuevos atributos serían necesarios y qué métodos adicionales deberían incorporarse para representar correctamente estas nuevas funcionalidades. Detalla también si alguno de los atributos o métodos debería cambiar de visibilidad, tipo de dato o parámetros, y explica por qué estos cambios mejoran la representación del sistema en UML.

• AC 408 (RA5 / / IC1 / 1p). Imagina que recibes de un cliente una descripción poco precisa de un sistema para gestionar reservas en un centro deportivo: “Los clientes podrán reservar pistas, anular sus reservas, consultar horarios y pagar desde la aplicación”. A partir de esta información incompleta, redacta un texto en el que propongas qué clases deberían existir en este sistema y expliques por qué.

  Describe qué atributos mínimos crees que necesita cada clase, justificando su tipo de dato y visibilidad. A continuación, explica qué métodos debería implementar cada clase para cubrir la funcionalidad pedida y razona cómo se organizarían las relaciones entre ellas (por ejemplo, asociación o dependencia), aunque no dibujes todavía el diagrama UML. Termina indicando qué información te falta y cómo influiría en el diseño definitivo.

• AC 409 (RA5 / / IC1 / 1p). Piensa en un objeto cotidiano, como un coche, un móvil, una bicicleta o incluso una lámpara inteligente. Redacta un texto en el que expliques cómo transformarías ese objeto real en una clase UML, identificando qué atributos representarían su estado y qué métodos representarían sus acciones o funcionalidades reales. A continuación, reflexiona sobre cuáles de esos atributos deberían ser privados y cuáles podrían ser públicos, y justifica tu decisión basándote en buenas prácticas de encapsulación.

  Finalmente, describe al menos dos métodos que, aunque no existan en el objeto físico, serían necesarios en el objeto software para poder gestionarlo correctamente dentro de un programa informático (por ejemplo, métodos de inicialización, validación o actualización interna).

• PR 410 (RA5 / / IC1 / 5p). La editorial “Lectura Viva” quiere desarrollar un sistema digital para gestionar tanto su catálogo de libros como la relación con autores y distribuidoras. El cliente todavía no conoce exactamente sus necesidades, pero te ha enviado una explicación general: “Queremos controlar los libros publicados, cada uno con su autor, su ISBN, su editor responsable y su estado de impresión. También nos interesa saber qué distribuidoras trabajan con cada libro y registrar las ventas mensuales para poder generar informes”.

  A partir de esta información, redacta un texto completo en el que desarrolles todo el proceso de análisis, diseño y modelado UML. En la primera parte del texto, identifica qué clases debería tener el sistema y explica por qué son necesarias. Después, detalla qué atributos formarían parte de cada clase, especificando su tipo de dato, su visibilidad y si habría que incluir valores por defecto o restricciones. A continuación, describe qué métodos serían necesarios en cada clase para representar su comportamiento natural, señalando qué métodos deben devolver valores y cuáles deberían recibir parámetros. Explica también cómo se relacionarían las clases entre sí (uno a muchos, muchos a muchos, composición, agregación…) y justifica cada relación en términos de las reglas del dominio real.

  En una segunda fase del texto, explica cómo evolucionaría el diagrama UML inicial conforme avanzara el proyecto: qué información incluirías en una versión preliminar (por ejemplo, solo nombres de clases, atributos y métodos principales) y qué detalles añadirías más adelante (modificadores de acceso, tipos, parámetros específicos, relaciones más precisas, multiplicidades, dependencias). Por último, reflexiona sobre qué posibles ampliaciones podrían aparecer en futuras versiones del proyecto (como la incorporación de libros electrónicos, múltiples autores por obra, control de stock o gestión de derechos) y describe cómo afectaría esto a las clases y a los métodos ya definidos, mostrando que el diseño UML debe ser flexible y adaptable.