Diseño de objetos
Definición
Durante el diseño de objetos refinamos y detallamos ambos conjuntos de objetos e identificamos cualesquier objetos de solución faltantes necesarios para completar el sistema.
Conceptos de diseño de objetos
Objetos de aplicación
Representa conceptos del dominio que manipula el sistema.
Objetos de solución
Representan componentes de apoyo que no tienen una contraparte en el dominio de aplicación, como los almacenes de datos persistentes o los objetos de interfaz de usuario.
Tipo
El tipo de un atributo especifica el rango de valores que puede tomar el atributo y las operaciones que pueden aplicarse al atributo.
Ejemplo
Sí tuviéramos una clase llamada TableHash y un atributo denominado "numElementos", esto representa el número actual de entradas en una TablaHash dada.
Su tipo es int, indicando que es un número entero.
El tipo del atributo "numElementos" también indica las operaciones que pueden aplicarse a este atributo:
Podemos sumar o restar otros enteros a "numElementos".
Firma
Los tipos de cada parámetro y el tipo de valor de retorno se le llama firma de la operación.
Ejemplo
El método put() de la clase TablaHash
toma dos parámetros de tipo Object y no tiene valor de retorno.
El tipo de firma para la operación put() es entonces:
(Object, Object) : void.
Visibilidad
La visibilidad de un atributo o una operación especifica si puede ser usada por otras clases
o no.
Tipos de niveles de visibilidad
Privado
Solo puede tener acceso a un atributo privado la clase en la que está definido.
Protegido
La clase en la que están definidos y cualquier descendiente de la clase pueden tener acceso a un atributo u operación protegidos.
Público
Cualquier clase puede tener acceso a un atributo u operación püblico.
Contratos
Especifica restricciones que debe satisfacer el llamador antes de usar la clase, así como las restricciones que asegura cumplir el llamado cuando se le usa.
Los contratos incluyen tres tipos de restricciones.
Invariantes
Son restricciones asociadas con clases o interfaces. Los invariantes se usan
para especificar restricciones de consistencia entre atributos de clase.
Ejemplo
Sí en la clase Persona tenemos un atributo denominado "edad", entonces, su restricción invariante sería, que la edad NUNCA puede tomar un valor menor o igual a cero.
Precondición
Es un predicado que debe ser cierto antes de que se llame a una
operación. Las precondiciones están asociadas con una operación especifica. Las precondiciones se usan para especificar restricciones que debe satisfacer el llamador antes de llamar a una operación.
Ejemplo
El factorial de un número sólo está definido para valores positivos (o cero).
Por lo tanto
Un método que calcule el factorial de un número exigirá que dicho número sea mayor o igual que cero.
Poscondición
Es un predicado que debe ser cierto después de que se llama a una
operación. Las poscondiciones están asociadas con una operación especifica. Las poscondiciones se usan para especificar restricciones que el objeto debe asegurar después de la invocación de la operación.
Ejemplo
El resultado de un factorial es siempre un entero mayor o igual que 1.
De este modo
Un método que calcula el factorial de un número dado tendría como postcondiciones que el resultado debe ser un entero y que éste debe ser mayor o igual que 1.
Diseño de sistemas orientado a objetos
Definición
El diseño de sistemas es el proceso de definir los elementos de un sistema, como los módulos, arquitectura, componentes, interfaces y datos para un sistema basado en los requisitos especificados.
Conceptos de diseño de sistemas
Subsistemas y clases
Para reducir la complejidad del dominio de aplicación identificamos partes más pequeñas, llamadas clases, y las organizamos en paquetes.
En otros lenguajes,
como c o c++, los subsistemas no están modelados en forma explicita y, en ese caso, los desarrolladores usan convenciones para el agrupamiento de clases (por ejemplo, un subsistema puede representarse como un directorio que contiene todos los archivos que implementan el subsistema).
Servicios
El servicio de un subsistema
Se caracteriza por los servicios que proporciona a otros subsistemas.
Un servicio
es un conjunto de operaciones relacionadas que comparten un propósito comün.
Acoplamiento
Es la
La fuerza de las dependencias entre dos subsistemas. Si dos subsistemas
están poco acoplados son relativamente independientes.
Por lo tanto
Las modificaciones a uno de los subsistemas tendrá poco impacto en el otro.
Capas y particiones
El objetivo del diseño del sistema es manejar la complejidad dividiendo el sistema en partes más manejables.
Esto puede lograrse mediante un enfoque de dividir y conquistar.
en donde
Dividimos las partes en forma reiterada hasta que son bastante simples para ser manejadas por una persona o un equipo.
Interfaces
La interfaz de un subsistema
Es el conjunto de operaciones de un subsistema que está disponible para otros subsistemas forma la interfaz del subsistema.
Se lo CONOCE también como interfaz de programación de aplicaciones (API, por sus siglas en inglés), incluye el nombre de las operaciones, sus parámetros, sus tipos y sus valores de retorno.
Coherencia
Es la
Fuerza de las dependencias dentro de un subsistema. Una propiedad deseable de una descomposición en subsistemas es que conduzca a subsistemas con coherencia alta.
Si un subsistema contiene muchos objetos que están relacionados entre si y realizan tareas similares, su coherencia es alta.
Si un subsistema contiene varios objetos que no están relacionados, su coherencia es baja.
Patrones de diseño
Definición
Es una solución general repetible a un problema común en el diseño de software.
Es una descripción o plantilla sobre cómo resolver un problema que se puede utilizar en muchas situaciones diferentes.
Tipos
Creacional
Estos patrones de diseño tienen que ver con la instanciación de clases.
Ejemplo
Patrón Singleton
Una clase de la que solo puede existir una instancia.
Estructural
Estos patrones de diseño tienen que ver con la composición de clases y objetos.
Ejemplo
Patrón Fuente
Separa la interfaz de un objeto de su implementación.
Características
Es una solución probada a problemas que se repiten.
Son soluciones reutilizables a problemas comunes.
El patrón de diseño no se puede implementar directamente.
Los patrones de diseño pueden acelerar el proceso de desarrollo al proporcionar paradigmas de desarrollo probados y comprobados.
Los patrones de diseño no son frameworks (marcos de trabajo).
Documentación
Enfoques prinicipales
Autocontenido generado a partir del modelo
Como extensión del RAD (rapid application development)
Incrustado en el código fuente
Uso
Intercambiar la información de interfaz entre equipos
Además
Como referencias durante pruebas
Permite
A los desarrolladores comprender el subsistema lo bastante bien como para usarlo.
Describe
Compromisos del diseño tomados por los desarrolladores