Clases y objetos
| |
Mientras que un objeto es una entidad que existe en
el tiempo y en el espacio, una clase representa sólo una abstracción,
«la esencia» del objeto, si se puede decir así. |
 |
| Grady Booch |
Sin pretender escribir un tratado sobre clases y objetos (para
profundizar en estos temas existe abundante bibliografía),
trataré de ofrecer, a grandes rasgos, una pequeña
introducción a algunos conceptos básicos de la
Orientación a Objetos (OO).
Clases
Comencemos con algunos ejemplos: Marte, la pirámide de Keops, la
carretera N1, Carlos Bergante, la sota de espadas... son objetos.
Un objeto refleja algún aspecto del mundo que intentamos
representar como base para la construcción de una determinada
aplicación (cuenta con unos límites definidos y significado
para ésta).
Una clase representa la esencia de un grupo de objetos
(planeta, monumento, vía, persona, naipe... son clases a las
que pertenecen los objetos antes citados como ejemplo), sus
propiedades, las operaciones aplicables a éstos, sus
comportamientos.
Una representación de las clases Bicicleta, Planeta,
Libro y Naipe
 |
|
|
|
| En su libro "Software Engineering. A Practitioner's Approach"
[PRE01], Pressman define clase como una
"descripción generalizada (por ejemplo, una plantilla, un
patrón o un prototipo) que describe una colección de objetos
similares". Por su parte, los creadores de UML, en "The Unified Modeling
Language. Reference manual." [RUM99], dan su
definición del concepto de clase como "descriptor de un conjunto de
objetos que comparten los mismos atributos, operaciones, métodos,
relaciones y comportamiento", y la de los objetos como
"entidades discretas, con límites bien definidos y con
identidad, que encapsulan el estado y el comportamiento". |
|
|
|
|
|
Con el término instancia definimos un objeto
concreto de una clase. Por ejemplo, Marte, Tierra, Saturno y Urano
son objetos de la clase Planeta, se dice que son instancias de la
clase Planeta; a su vez el rey de copas y la sota de espadas son
instancias de la clase Naipe.
Instancias de la clase Naipe
Las propiedades de los objetos vienen dadas por los valores que
tomen una serie de descriptores definidos por las clases a las que
éstos pertenezcan. Estos descriptores se denominan atributos.
Por ejemplo, supongamos que tenemos una clase Persona con la que
queremos representar a las personas del mundo real; cualquier persona
contará con una serie de propiedades que de alguna forma la
definen: nombre, apellido, altura, peso, fecha de nacimiento, ... que
deberán quedar reflejadas como atributos de la clase Persona
(no se trata de incluir como atributos todas las
propiedades de una persona, sino tan sólo las relevantes
para el modelo que estemos construyendo; no tiene sentido que por
ejemplo se incluya como atributo el Número de Identificación
Fiscal si estamos modelando un sencillo listín telefónico,
pero sí podrá ser necesario si se trata de modelar un
sistema que permita a una empresa un tratamiento de clientes).
Una operación es una función aplicable a los
objetos de una clase. La implementación de una operación
para una clase contituye un método de ésta
(normalmente usaremos indistintamente los términos operación,
método y servicio, también se suele hablar de funciones
miembro; personalmente prefiero hablar de métodos). La
interacción con los objetos se lleva a cabo mediante lo que se
llama paso de mensajes al objeto en cuestión. Al pasar
un mensaje a un objeto estaremos activando un método de
éste, es decir, ejecutando una operación concreta de la
clase a la que pertenece el objeto, de modo que éste iniciará
un comportamiento determinado.
En "Object-Oriented modeling and design" [RUM91],
Rumbaugh plantea la pregunta: "Si los objetos son el tema central del
modelado de objetos ¿por qué preocuparse por las clases?".
Pues bien, aquí entra en juego el concepto de abstracción
y las ventajas que nos proporciona; en palabras de Rumbaugh: "es posible
escribir operaciones una sóla vez para cada clase de tal manera que,
todos los objetos de la clase se beneficien de la reutilización
del código" (las ventajas son aún mayores si a
ésto añadimos el concepto de herencia, por el que se
beneficiarán también todos los objetos de las subclases
que hereden los métodos).
Veamos un ejemplo de la representación de clases (conceptualmente,
mostrando atributos y mostrando tanto atributos como métodos) para
una clase Bicicleta:
Y a continuación una instancia de la clase, el objeto miBicicleta:
 |
miBicicleta:Bicicleta
piñones = 6
platos = 3
piñónActual = 5
platoActual = 2
velocidad = 0
frenoDelantero = 0
frenoTrasero = 0
alturaSillín = 20
|
Mi bicicleta: Una instancia de Bicicleta
(ops!, sí, la que aparece en la foto es realmente mi bicicleta ;-D)
Herencia
Las asociaciones describen relaciones entre clases. A
través de una relación es-un (is-a) entre dos clases,
la generalización se convierte en un potente mecanismo
que permite derivar una clase de otra (que llamaremos superclase), de
modo que esta nueva clase (subclase) hereda las características
de la superclase, pudiendo añadir además sus propios
atributos y métodos. En UML esta relación se representa
mediante una línea con un triángulo vacío en el
extremo correspondiente a la superclase.
En este diagrama vemos por ejemplo que una Autopista es una ViaInterurbana,
y ésta a su vez es una Vía.
Herencia: Subclases de Via
En el siguiente diagrama tomemos como ejemplo la clase VehiculoMotor. Podemos
considerar que un vehículo de motor cuenta con las propiedades de un
vehículo (su superclase es Vehiculo) pero además atributos y
métodos propios dado que se caracteriza además por tener un motor
de combustión; si por ejemplo tiene un atributo centimetrosCubicos
público, será una propiedad que heredará la clase Automóvil
y a su vez Motocicleta (una Motocicleta es un Automóvil y éste es
un VehiculoMotor).
Herencia: Subclases de Vehiculo
El concepto de herencia es de gran utilidad, sin embargo debe evitarse
en la medida de lo posible contar con generalizaciones demasiado anidadas.
Hasta aquí esta pequeña introducción; hay muchos
más conceptos, así que para profundizar en ellos (polimorfismo,
clases abstractas, agregación, composición, cualificadores,
atributos y métodos públicos, protegidos y privados, etc.)
te remito a la abundante bibliografía sobre Orientación a
Objetos. Para empezar puedes echar un vistazo a los
libros referenciados en esta página :-)
Agregación y composición
Notas, observaciones, citas...
+ Importancia del modelo de objetos.-
..., el más importante es el modelo de objetos porque es necesario para
describir qué está cambiando o transformándose antes
de describir cuándo o cómo cambia.
...
El modelo de objetos es el más importante de los tres
modelos. Se hará hincapié en construir un sistema en
torno a los objetos y no en torno a la funcionalidad, porque el
modelo de objetos se corresponde con el mundo real de manera más
fiel y, por tanto, es más flexible frente al cambio. Los
modelos de objetos proporcionan una representación gráfica
intuitiva del sistema y son valiosos para comunicarse con el cliente
y para documentar la estructura del sistema. |
James Rumbaugh
Modelado y diseño orientados a objetos.
Metodología OMT.
|
|
Observación: OMT es una metodología
guiada por los datos. Sorprende ver que su creador, Rumbaugh, es también
uno de los creadores de RUP (Proceso Unificado de Rational), unos
cuantos años después, si tenemos en cuenta que RUP es
guiado por los casos de uso en lugar de por los datos. Entramos en el
ya antiguo debate metodológico: ¿por dónde
empezar?, ¿datos o procesos?, ¿qué debería
guiar un proceso de desarrollo de software?. Personalmente me atrae
la idea de al menos comenzar por los datos, por un modelo conceptual,
sin embargo, ya orientando el desarrollo hacia el usuario final, he
encontrado de gran utilidad la utilización de casos de uso,
sobre todo para la especificación inicial de lo que se pretende que
haga el sistema a construir. En palabras de Rumbaugh [RUM91],
incluso como consejo para usar OMT, "no hay que empezar a construir el modelo
de objetos anotando clases, asociaciones y herencias. En primer lugar hay que
comprender el problema que se debe resolver. El contenido de un modelo de
objetos está determinado por su relevancia para la solución",
y ahí, precisamente en la comprensión del problema a resolver,
es donde veo de gran utilidad el empleo de casos de uso.
|
+ No deben utilizarse ID's.-
| Algunos medios de implementación tales como muchas bases de
datos, exigen que el objeto tenga un identificador único que
se reconozca a cada objeto. Los identificadores de objetos explícitos
no son necesarios en el modelo de objetos, cada uno posee su propia
identidad única. ... Los identificadores son un artefacto de
la computadora y no tienen un significado intrínseco más
allá de la identificación de un objeto.
No hay que confundir los identificadores internos con atributos
del mundo real. Los identificadores internos son solamente una
comodidad de implementación y no tienen significado en el
dominio del problema.
|
James Rumbaugh
Modelado y diseño orientados a objetos.
Metodología OMT.
|
Referencias bibliográficas.
|
