Principios de la programación orientada a objetos (III)

Cómo identificar las Clases y Objetos

En el mundo real es sencillo identificar los objetos, sus atributos y sus funciones, pero a la hora de hacer un programa informático esta identificación no resulta tan evidente. Los objetos desde la realidad se manifiestan como:

Entidades Externas. Pueden ser cosas o personas externos al sistema pero que producen o consumen información del sistema.

Cosas. Objetos físicos del sistema, informes, facturas, maquinas, etc.

Ocurrencias o sucesos. Cuando se produce un cambio en el tiempo, sacar dinero de una cuenta, una máquina llega al final de carrera, etc.

Papeles o roles. Los desempeñados por personas que interactúan en el sistema

Unidades organizacionales. Si son relevantes en un sistema, división, equipo, etc.

Lugares. Establecidos en el contexto del sistema. Planta, Nº de aparcamiento, Plaza, Almacén, etc.

Estructuras. Una clase de objetos, maquinas, sensores, etc.

Así por ejemplo para un programa que juegue al ajedrez podemos identificar:

Clase/ Objeto Potencial

Jugador -> entidad externa o rol

Pieza ->cosa

Tablero -> cosa

Posición -> atributo de la pieza

Captura -> ocurrencia

Movimiento -> ocurrencia

Color -> atributo de la pieza

Para definir las clases y los objetos conviene analizar sintácticamente el enunciado o especificación del software a desarrollar detectando los posibles objetos (nombres) y los posibles métodos (verbos). Se han definido seis características para considerar si se incluye un objeto en un modelo de análisis:

Servicios Necesarios. Debe ser capaz de cambiar el valor de sus atributos a través de un conjunto de operaciones identificables.

Información retenida. La información acerca del objeto debe ser recordada para que el sistema funcione.

Atributos Múltiples. Un objeto debe tener atributos múltiples, si sólo tiene uno se puede considerar durante el análisis pero seguramente se pueda incluir dicho atributo dentro de otro objeto 

Operaciones Comunes. Las operaciones tienen que ser aplicables a todas las ocurrencias del objeto.

Atributos Comunes. Los atributos tienen que ser aplicables a todas las ocurrencias del objeto.

Requisitos esenciales. Las entidades externas que intervienen en el problema consumiendo o produciendo información esencial para el sistema también deben ser incluidas como objetos.

Para incluir un objeto en nuestro modelo, debe satisfacer la mayoría de los puntos mostrados anteriormente. Una vez elegido el objeto, sus atributos se buscan con la premisa de que definan completamente los objetos que los hacen únicos.

Si retomamos el ejemplo del ajedrez podemos ver si cumplen los requisitos.

Clase/ Objeto Potencial

Jugador -> entidad externa o rol Rechazado: no cumple muchas características.

Pieza ->cosa Aceptado: Cumple todas

Tablero -> cosa Rechazado: solo contiene la posición que pasa a atributo de la pieza

Posición -> atributo de la pieza.

Pasa a atributo de la pieza

Captura -> ocurrencia.

Pasa a método de la pieza

Movimiento -> ocurrencia.

Pasa a método de la pieza

Color -> atributo de la pieza.

Pasa a atributo de la pieza

Para encontrar las operaciones (métodos) hay que prestar atención a los verbos de la definición del sistema. Así en la definición del juego de ajedrez el verbo mover es importante y define un método. También existe el verbo capturar, por lo que habrá que tenerlo en cuenta a la hora de diseñar la clase.

Finalmente tendremos sólo una clase principal llamada Pieza que tendrá como propiedades el color de la pieza y su posición sobre el tablero, también será necesario añadir otra propiedad que no viene en la lista que nos diga el tipo de pieza de que se trata.

Tendrá un método mover y otro capturar que puede fusionarse como caso especial del método mover. También es conveniente heredar una clase para cada tipo de pieza. De este modo tendremos la clase padre Pieza con las clases hijas Peón, Torre, Caballo, Alfil, Rey y Reina, todas heredan todos los atributos como Color, Posición, etc. y cada una de ellas implementa un método diferente llamado Mover que incluye el caso especial Capturar. Dicho caso especial obliga a introducir otro atributo en la clase pieza que nos indique si la pieza está en juego o no. 

El sistema para un lenguaje concreto (Visual Basic.NET) se representaría así en UML: