En entradas anteriores hemos visto cómo dibujar Diagramas de casos de uso con UML, esos planos detallados de nuestra aplicación. El siguiente paso sería dibujar el «plano» de nuestro software, el Diagrama de clases. Sin embargo, para hacerlo necesitas saber qué clases tienes que incluir, ¿verdad? Esa es, sin duda, una de las preguntas clave del diseño orientado a objetos: ¿Cómo identifico las clases que necesito?

No te preocupes, existen técnicas y enfoques sistemáticos que te ayudarán a descubrir las clases candidatas escondidas en los requisitos de tu proyecto. ¡Vamos a verlas!

¿Por Qué es Tan Importante Identificar las Clases Correctas? 🤔

Como intuirás, identificar las clases adecuadas es crucial porque:

• Forman la Espina Dorsal del Sistema: Son los bloques de construcción fundamentales de tu código.
• Impactan en la Calidad: Una buena elección de clases lleva a un diseño más cohesivo, con bajo acoplamiento, más fácil de entender, mantener y extender. Una mala elección… bueno, prepara café para largas noches de depuración.
• Reflejan el Dominio del Problema: Las clases bien elegidas suelen modelar conceptos del mundo real o del dominio del problema que estás resolviendo, haciendo el sistema más intuitivo.

La fuente principal: ¡los Requisitos!

Toda esa información que recopilaste y documentaste durante el análisis (descripciones de casos de uso, historias de usuario, especificaciones funcionales) es oro puro para encontrar clases.

Las clases representan abstracciones, conceptos clave del sistema. A menudo, estas abstracciones se manifiestan como sustantivos o frases nominales en la descripción del problema.

Técnicas para Identificar Clases Candidatas

Aquí tienes algunas técnicas comunes y efectivas:

1. Análisis de Sustantivos y Frases Nominales (La Técnica Clásica)

Esta es probablemente la técnica más utilizada y un excelente punto de partida:

1. Lee Detenidamente: Repasa tus documentos de requisitos (casos de uso, historias de usuario, descripción del problema).
2. Subraya los Sustantivos: Identifica y lista todos los sustantivos y frases nominales que encuentres. ¡No descartes nada al principio!
3. Filtra y Refina: Ahora viene la parte crítica. Revisa la lista y aplica criterios para decidir si cada sustantivo realmente representa una clase candidata relevante para tu sistema.

Ejemplo (Extracto de Caso de Uso «Reservar Habitación»):

«El Cliente busca Habitaciones disponibles según Criterios (Fechas, Tipo). El Sistema muestra la Disponibilidad y el Precio. El Cliente selecciona una Habitación y proporciona Datos de Pago. El Sistema procesa el Pago a través de la Pasarela de Pago y genera una Reserva y una Confirmación.»

Lista Inicial de Sustantivos/Frases Nominales:

• Cliente
• Habitación / Habitaciones
• Criterios
• Fechas
• Tipo (de habitación)
• Sistema
• Disponibilidad
• Precio
• Datos de Pago
• Pago
• Pasarela de Pago
• Reserva
• Confirmación

¡Ahora a Filtrar!

2. Tarjetas CRC (Clase-Responsabilidad-Colaborador)

Esta es una técnica más dinámica y colaborativa, genial para trabajar en equipo:

1. Prepara Tarjetas: Usa fichas o post-its.
2. Identifica Clases Candidatas: Como en el método anterior, o basándote en la intuición inicial. Escribe el nombre de una clase candidata en la parte superior de cada tarjeta.
3. Define Responsabilidades: Para cada clase, piensa: ¿Qué hace esta clase? ¿Qué sabe (información que maneja)? Anota estas responsabilidades en la tarjeta. Suelen ser verbos o frases verbales.
4. Identifica Colaboradores: Piensa: ¿Necesita esta clase ayuda de otras clases para cumplir sus responsabilidades? Anota los nombres de esas clases colaboradoras en la tarjeta.
5. Simula Escenarios: Representa casos de uso o escenarios moviendo las tarjetas, viendo cómo interactúan («colaboran») para realizar una tarea. Esto ayuda a validar las clases y sus responsabilidades.

Beneficios: Fomenta la discusión, ayuda a asignar comportamiento (responsabilidades) a las clases desde el principio y a entender las interacciones.

3. Identificar Conceptos del Dominio y Abstracciones del Mundo Real

A veces, las clases son evidentes porque representan cosas tangibles o conceptos bien definidos en el dominio del problema:

• Entidades Físicas: Coche, Edificio, Sensor, Producto.
• Roles: Empleado, Cliente, Administrador, Profesor.
• Incidentes, Eventos o Transacciones: Vuelo, Reserva, Compra, Matricula, Click.
• Estructuras: Factura (con sus LineasDeFactura), Documento (con sus Parrafos).

Piensa en los «actores» y las «cosas» importantes que se manejan en el sistema.

El Filtro Final: ¿Este Sustantivo Merece ser una Clase?

Una vez tienes tu lista de candidatos (especialmente del análisis de sustantivos), necesitas aplicar un filtro crítico. Hazte estas preguntas para cada candidato:

1. ¿Retiene Información (Tiene Estado/Atributos)? ¿Necesita recordar datos? Una clase suele tener atributos (variables) que describen su estado. Si es solo un valor simple (como Precio o Fecha en el ejemplo anterior), probablemente sea un atributo de otra clase (ej: Habitacion tiene un precio, Reserva tiene fechaEntrada y fechaSalida).
   • Ejemplo: Habitacion necesita saber su numero, tipo, estado (libre/ocupada), precioPorNoche. ¡Parece una buena clase! Precio por sí solo, quizás no.
2. ¿Tiene Comportamiento (Responsabilidades/Métodos)? ¿Realiza acciones? ¿Ofrece servicios a otras clases? Una clase suele tener métodos que definen lo que puede hacer.
   • Ejemplo: Reserva necesita poder confirmar(), cancelar(), calcularEstancia(). ¡Sí tiene comportamiento!
3. ¿Es un Concepto Único y Relevante? ¿Representa una abstracción significativa dentro del ámbito del sistema? ¿No es redundante con otra clase ya identificada?
   • Ejemplo: Cliente y Usuario podrían ser la misma clase o clases distintas dependiendo de los requisitos. Disponibilidad podría ser una clase o simplemente el resultado de una consulta sobre Habitacion.
4. ¿Es Más que un Simple Nombre o Descripción? A veces, un sustantivo es solo una etiqueta o un atributo. Tipo de habitación es probablemente un atributo de Habitacion, no una clase en sí misma (a menos que los tipos tuvieran comportamientos muy diferentes).
5. ¿No es un Actor Externo o el Sistema Entero? Sistema suele ser demasiado general (es el contexto). Pasarela de Pago podría ser una clase adaptadora dentro de tu sistema que interactúa con el sistema externo real, pero el sistema externo en sí mismo es un actor.

Aplicando el Filtro al Ejemplo «Reservar Habitación»

• Clases Probables: Cliente, Habitacion, Reserva.
• Clases Posibles (a evaluar más): Pago (¿o es parte de Reserva?), Confirmacion (¿un objeto, un documento, o una acción?), PasarelaPagoAdapter (para interactuar con el sistema externo).
• Probablemente Atributos: Criterios, Fechas, Tipo, Disponibilidad, Precio, Datos de Pago.
• Probablemente No Clases (en este nivel): Sistema.

¡El Diseño es Iterativo!

Es crucial entender que la identificación de clases no es un proceso lineal y perfecto que haces una sola vez. Es iterativo:

1. Identificas candidatos iniciales.
2. Los refinas usando los criterios.
3. Empiezas a dibujar diagramas de clases preliminares.
4. Añades atributos y métodos.
5. Modelas relaciones.
6. Al hacer esto, descubres nuevas clases que te faltaban o te das cuenta de que algunas clases candidatas no eran necesarias o deberían fusionarse.
7. ¡Vuelves a refinar!

Este ciclo se repite a medida que tu comprensión del sistema se profundiza.

Errores Comunes al Identificar Clases

• Clases «Dios»: Crear una o pocas clases que saben y hacen demasiado. Malísimo para la cohesión y el acoplamiento.
• Clases Anémicas: Clases que solo tienen atributos (getters/setters) pero ningún comportamiento propio. La lógica está dispersa en otras partes.
• Clases Duplicadas: Crear dos clases que representan el mismo concepto.
• Clases que son Solo Funciones: Crear una clase solo para albergar una función que podría pertenecer a otra clase más lógica.
• Nombrar Mal: Usar nombres ambiguos, verbos en lugar de sustantivos, o nombres demasiado genéricos (Manager, Processor, Data).

Conclusión

Identificar las clases correctas es una mezcla de técnica, experiencia y buen juicio. Empieza con el análisis de sustantivos, considera usar CRC Cards si trabajas en equipo, y sobre todo, filtra tus candidatos haciéndote las preguntas clave: ¿tiene estado? ¿tiene comportamiento? ¿es relevante?.

Recuerda que es un proceso iterativo. No tengas miedo de equivocarte al principio; la clave está en refinar tu modelo a medida que avanzas. ¡Con práctica, te convertirás en un hábil detective capaz de encontrar las abstracciones perfectas para tus diseños!

¿Qué técnica te parece más útil? ¿Te has encontrado alguna vez con una clase difícil de identificar? ¡Comparte tus pensamientos en los comentarios! 👇