Translate

lunes, 22 de octubre de 2012

OBJETOS 4. LOS OBJETOS DE LA PROGRAMACIÓN ORIENTADA A OBJETOS.


El aparecimiento de nuevos campos de la ciencia y tecnología termina por afectar a los demás; y esto es particularmente cierto, en una dimensión incalculable, para la informática. En este momento, me interesa resaltar la capacidad discriminatoria que exige la programación.
En la medida en que una computadora hace exclusivamente aquello que le ordenas de la manera más detallada posible, los procesos deben ser partidos en sus componentes para que puedan ser entendidos por la máquina.
Por otra parte, la Programación Orientada a Objetos, (POO), amplió el campo de aquello que solíamos considerar objetos, permitió niveles más altos de abstracción y una mejor comprensión de lo que son estos. Veamos ahora cómo la POO nos ayuda a comprender de mejor manera lo que es el diseño de objetos.
La POO parte del mundo real para volver luego de un proceso a este: “Un objeto es un componente del mundo real que se transforma en el dominio del software… consta de una estructura de datos privada y procesos, llamados operaciones o métodos, que pueden transformar legítimamente la estructura de datos.”(372)
Más adelante se establece que: “Muchos objetos tienen unas características razonablemente similares y ejecutan operaciones razonablemente similares… Todos los objetos son miembros de una clase más amplia y heredan la estructura de datos privada y las operaciones que se han definido para esa clase.”(374) De donde se deduce que “un objeto es una instancia de una clase más amplia.” (374)
Retengamos algunas ideas centrales: un objeto tiene una estructura, existen operaciones que se realizan con objetos, siempre pertenecen a una clase o conjunto –se encuentran indexados, son instancias-, sus características pueden trasladarse a otros objetos similares: se heredan.
Creo que es fácil ver cómo estas características establecidas por la POO se aplican a los objetos del diseño y, al mismo tiempo, contribuyen a entenderlos con más precisión. Se podría hacer el ejercicio de tomar un objeto diseñado y analizar cómo cumple la serie de requisitos que se han señalado.
Tomemos un sillón de mimbre y preguntémonos qué le pasa cuando entra a formar parte del dominio del diseño:
-          ¿A qué clase pertenece?
-          ¿De qué manera específica es una instancia de esa clase, como la relación entre type y token?
-          ¿Cuál es su estructura?
-          ¿Cuáles son las operaciones que sirvieron para construirlo y las que se pueden hacer con él una vez fabricado?
-          ¿Qué aspectos estructurales u operacionales son capaces de trasladarse a otros objetos?
(Pressman Roger, Ingeniería del software. Un enfoque práctico, McGraw-Hill, México, 1988)

No hay comentarios:

Publicar un comentario