El modelo de objetos (II/XII)
25 Febrero 2009
Continúo con mi lectura.
El modelo de objetos es una evolución de los paradigmas y lenguajes de programación, ya que existe un límite en la cantidad de complejidad que puede manejar la decomposición algorítmica.
La programación orientada a objetos es un método de implementación en el cual los programas se organizan como colecciones de objetos que cooperan, representando cada uno de ellos una instancia de alguna clase, siendo estas clases miembros de una jerarquía de clases unida por relaciones de herencia.
El diseño orientado a objetos es un método de diseño que abarca el proceso de descomposición orientada a objetos y una notación para dibujar los modelos físicos y lógicos, asi como estáticos y dinámicos del sistema.
El análisis orientado a objetos examina los requisitos desde la perspectiva de las clases y los objetos encontrados en el vocabulario del dominio del problema. Los productos del análisis orientado a objetos sirven como punto de partida para el diseño orientado a objetos.; los productos del diseño orientado a objetos sirven como modelo para implementar el sistema utilizando métodos de la programación orientada a objetos.
La tecnología orientada a objetos se basa en el modelo de objetos, cuyos principios se pueden categorizar como:
- Imprescindibles. Un modelo sin alguno de estos elementos no se puede considerar orientado a objetos.
- Abstracción.
- Encapsulación.
- Modularidad.
- Jerarquía.
- Complementarios. Son útiles, pero no esenciales.
- Tipado.
- Concurrencia.
- Persistencia.
Una abstracción denota las características esenciales de un objeto que lo distinguen de otros tipos de objeto y provee unos límites conceptuales claros, relativos a la perspectiva del observador. La abstracción separa el comportamiento esencial del objeto de su implementación.
Las abstracciones de entidad se corresponden con el vocabulario del dominio del problema y establecen un modelo de contrato ya que representan la visión exterior que cada objeto define como un contrato del cual otros objetos dependen. El protocolo es el orden en el cual se deben llamar al conjunto de operaciones que ofrece un objeto. Todas las abstracciones tienen propiedades estáticas y dinámicas. La separación de responsabilidades hace que cada abstracción esté más cohesionada.
La encapsulación es el proceso de compartimentar los elementos de una abstracción que constituye su estructura y comportamiento, separando la interfaz contractual de una abstracción de su implementación. La encapsulación se centra en la implementación que permite la abstracción, proveyendo barreras explícitas entre diferentes abstracciones y creando así una clara separación de aspectos. La encapsulación inteligente localiza las decisiones de diseño que más probablemente van a cambiar. La habilidad de cambiar sin molestar a los objetos clientes es un beneficio esencial de la encapsulación.
La modularidad reduce la complejidad en algún grado creando fronteras (interfaces) bien definidas y documentadas dentro del programa. Los módulos son contenedores físicos en los cuales se declaran las clases y los objetos en el diseño lógico. La agrupación lógica de clases y objetos relacionados en el mismo módulo permite exponer sólo los elementos que otros módulos deben ver. Se puede reducir el coste del software permitiendo que los módulos se diseñen y revisen independientemente. El coste de recompilar un módulo es relativamente pequeño, mientras que el coste de recompilar una interfaz es alto. Se debe ocultar el máximo posible en la implementación de un módulo. Los módulos permiten la reutilización. Los módulos también permite realizar la asignación de trabajo y gestionar la relación con subcontratas. También se debe tener en cuenta la seguridad cuando se crean los módulos.
La jerarquía es un rango u orden de abstracciones. Las dos jerarquías principales son las de estructura de clases (“es un”) y la de estructura de objetos (“es parte de”). La herencia es la jerarquía de clase más importante, que consiste en que una clase comparte su estructura o comportamiento definiado en una o más clases. Normalmente, una subclase aumenta o redefine a la superclase, creando una especialización. La prueba de la herencia es la siguiente: “si b no es un tipo de A, entonces B no debe heredar de A”. La herencia múltiple permite heredar de varias clases a la vez. La herencia múltiple puede causar un choque cuando dos o más superclases proveen un campo u operación con el mismo nombre o firma que otra superclase. La herencia repetida ocurre cuadno dos o más superclases comparten una superclase común.
El tipado es el forzado de la clase de un objeto. Se puede usar indistintamente tipo o clase, aunque no son exactamente lo mismo. El uso de polimorfismo puede mitigar la necesidad de la identificación de tipo durante la ejecución. El polimorfismo denota objetos de diferentes clases que están relacionados por una superclase común. La seguridad ofrecida por un lenguaje de tipado fuerte compensa la flexibilidad que se pierde.
La concurrencia permite manejar diferentes eventos simultaneamente. Puede ser pesada o ligera, dependiendo de si la maneja el sistema operativo o un proceso del sistema operativo.
La persistencia es una propiedad de un objeto según la cual su existencia trasciende el tiempo y/o el espacio.
Los beneficios del modelo de objetos son:
- Ayuda a usar los lenguajes orientados a objetos.
- Permite crear frameworks reutilizables.
- Produce sistemas intermedios estables.
- Es inteligible para el conocimiento humano.
En el libro habla del “principio de mínimo asombro”, en referencia a que una abstracción es la interfaz que un objeto ofrece y que el resto de objetos pueden confiar en esa interfaz. Esto me ha recordado a otro libro que he leído hace poco, Clean code de Robert C. Martin que puedes ver aquí, donde se pregunta a varios autores relevantes cómo debe ser un código bien hecho, y uno de ellos hace referencia a un código sin sorpresas, donde el comportamiento sea previsible sólo leyéndolo.
Object-Oriented Analysis and Design with Applications, Third Edition. Booch et al. Addison-Wesley, 2007. Cap. II.
