La estructura estática: las clases
Las clases nos brindan un mejor enfoque para el diseño modular: reutilización y extensibilidad.
Los objetos no son el sujeto. Los objetos siguen teniendo importancia para describir la ejecución de un sistema O-O. Pero la noción básica, de la que deriva todo en la tecnología de objetos, es la clase.
La definición de una clase es: “una clase es un tipo abstracto de dato equipado con una implementación posiblemente parcial”
La definición de una clase genera como subproducto la definición de “objeto”.
Evitar la confusión estándar. Una clase es un modelo y un objeto es una instancia de dicho modelo.
El molde y la instancia. La clase es un texto de software. Es estática; en otras palabras, existe independientemente de cualquier ejecución.
Con la introducción de la herencia será necesario distinguir entre instancias directas de una clase y sus instancias en el sentido más general.
Metaclases. Una metaclase es una clase cuyas instancias son en si mismas clases.
El papel de las clases. Las clases desempeñan dos papeles importantes: módulo y tipo.
Módulos y tipos. Un módulo es una unidad de descomposición del software, y solo afecta a la forma de los textos de software, no a lo que el software puede hacer.
Un tipo es una descripción estática de ciertos objetos dinámicos.
Un sistema de tipos uniforme. Un aspecto importante del enfoque O-O tal como se va a desarrollar es la sencillez y la uniformidad del sistema de tipos, que se deriva de una propiedad fundamental: “todo objeto es una instancia de alguna clase.”
Atributos y rutinas. Todo tipo abstracto de dato como PUNTO está caracterizado por un conjunto de funciones que describen las operaciones aplicables a las instancias del TAD.
Cuerpos de las rutinas y comentarios de encabezamiento. El cuerpo de una rutina es una sucesión de instrucciones.
El comentario de encabezamiento desempeña un papel especial, el cual, como reglas general de estilo, debiera aparecer al principio de cada rutina después de la palabra is, y con sangría.
Reglas de estilo. Las reglas de estilo deben aplicarse correctamente desde el mismo momento en que se empieza a escribir una clase.
El estilo O-O. El código de una clase describe las propiedades y el comportamiento de los objetos de un cierto tipo.
Clientes y proveedores. Sea P una clase. Una clase C que contenga una declaración de la forma a:P se dice que es un cliente de P. se dice entonces que P es un proveedor de C.
Identificación módulo-tipo. Funciona de la siguiente manera: las facilidades proporcionadas por la clase punto, vista como un módulo, son precisamente las operaciones disponibles para ser aplicadas a instancias de la clase punto, vista como un tipo.
Llamada a una característica. F1 Ningún elemento software se ejecuta excepto como parte de una llamada a una rutina. F2 Toda llamada tiene un receptor.
Ejecución de un sistema. Consta de 2 pasos: crear cierto objeto denominado objeto raíz a efectos de la ejecución, y aplicar cierto procedimiento llamado procedimiento de creación a ese objeto.
Exportar un atributo le da a los clientes derechos de acceso sobre él. Para modificarlo se requiere llamar al procedimiento exportado apropiado.
No hay una necesidad de una estructura de supermodelo que esté por encima de las clases.
El estilo modular promovido por el desarrollo orientado a objetos genera muchas rutinas pequeñas.
Como encontrar las clases
Identificar las clases es una de las tareas principales de la construcción de software orientado a objetos.
Identificar las clases es un proceso dual: sugerir clases y rechazar clases. Tan importante como identificar candidatos potenciales a clases es la necesidad de eliminar ideas inadecuadas.
Identificar las clases es identificar las abstracciones relevantes en el dominio que está siendo modelado y en el espacio de la solución.
Subrayar los nombres en el documento de requisitos so es una técnica suficiente para encontrar las clases, puesto que los resultados son muy dependientes de aspectos estilísticos.
Las clases de diseño suelen ser las mas difíciles de idear.
Al diseñar las clases externas se debe recordar que los objetos externos incluyen tanto concepto como cosas materiales.
Para decidir si un determinado concepto justifica definir una clase asociada, hay que aplicar el criterio de abstracción de datos.
Las clases de implementación incluyen tanto a las clases efectivas como a las equivalentes diferidas, que describen categoría abstractas de técnicas de implementación.
La herencia proporciona una vía para reutilizar diseños previos, a la vez que se adaptan.
Una forma de obtener clases es evaluar diseños candidatos y buscar alguna abstracción no reconocida, analizando en particular la transmisión de datos entre módulos.
Los casos de uso, o escenarios, pueden ser útiles como herramienta de validación y como guía para ultimar una implementación, pero no debiera usarse como mecanismo de análisis y diseño.
La mejor fuente de clases son las bibliotecas reutilizables.
Principios de diseño de clases
Las clases deben ser conocidas por su interfaz, que especifica los servicios ofrecidos independientemente de su implementación.
Los diseñadores de clases deberían tender a unas interfaces sencillas y coherentes.
Uno de los temas clave al diseñar módulos son las características que hay que exportar, y las que tienen que permanecer en secreto.
El diseño de módulos reutilizables no es necesariamente correcto a la primera, pero la interfaz debería estabilizarse al cabo de un cierto tiempo de utilización. En caso contrario, existe un error en la forma en que se ha diseñado la interfaz. El mecanismo de características y clases obsolete hace posible suavizar la transición hacia un diseño mejor.
Suele resultar fructífero tratar algunas de las estructuras de datos como si fuesen máquinas activas, con un estado interno que se recuerda de una invocación a una característica a la siguiente.
El uso correcto de aserciones (precondiciones, poscondiciones, invariantes) es esencial para documentar interfaces.
La mejor manera de abordar situaciones excepcionales es a través de unas estructuras de control estándar, bien sea mediante el esquema a priori, que comprueba la aplicabilidad antes de invocar a la operación, o a través del esquema a posteriori, que intenta realizar la operación y examina después si ha tenido o no éxito.
Sigue siendo necesario u mecanismo de excepciones disciplinado en aquellos casos en que la ejecución deba cancelas inmediatamente una operación potencialmente peligrosa.
