Clases O-O
ARTICULO
ESTRUCTURAS ESTATICAS: LAS CLASES
Los objetos son útiles pero no son nuevos. Son importantes porque describen la ejecución de un sistema Orientado a Objetos. La noción básica de la que deriva todo en la tecnología de objetos, es la clase. Una clase es un tipo abstracto de dato equipado con una implementación, se dice que es efectiva si la implementación es total de lo contrario es diferida. Los tipos abstractos de datos son utilizados en la etapa de análisis. Las instancias de una clase son llamados objetos. Las clases creadas son estáticas, es decir que existen en cualquier ejecución. Un objeto derivado de la clase es una estructura de datos dinámica es decir que existe solo en la memoria de la computadora durante la ejecución del sistema.
Una metaclase es una clase cuya instancia son las mismas clases. Estas traen más problemas que soluciones porque evitan la comprobación estática de tipos. Pero mayormente se los utiliza para lograr que un conjunto de características este disponible para las otras clases.
Las clases se las trata por módulos y por tipos. Un modulo es una unidad de descomposición del software, que solo afecta al texto del software y no a lo que el software realizara, por eso su noción es un concepto sintáctico. Un tipo es una descripción estática de ciertos objetos dinámicos, como los elementos de datos que serán procesados durante la ejecución del software, existen tipos predefinidos como integer , char y tipos definidos por el desarrollador como tipos registros, su noción es un concepto semántico, porque influye directamente en la ejecución del software.
Existen reglas de estilos que deben aplicarse desde en momento en que se empieza a escribir la clase.
Para llamar a una característica de una clase se debe seguir los siguientes principios:
ü Ningún elemento software se ejecuta excepto como parte de una llamada a una rutina.
ü Toda llamada tiene un receptor.
Para ejecutar un software Orientado a Objetos se debe seguir 2 pasos importantes:
ü Crear ciertos objetos llamados Objetos Raíz a efectos de la ejecución.
ü Aplicar cierto procedimiento llamado Procedimiento de Creación a ese objeto.
El objeto raíz es una instancia de cierta clase, la clase raíz del sistema, el procedimiento de creación es uno de los procedimientos de la clase raíz.
Las clases son componentes individuales de la construcción de software orientado a objetos, para formar un sistema que sea ejecutable se deben ensamblar las clases. Para crear el sistema se necesitan 3 cosas:
ü Un conjunto CC de clases llamado conjunto de clases del sistema.
ü La indicación de que clase en CC es la clase raíz.
ü La indicación de cuál de los procedimientos de la clase raíz es el procedimiento de creación raíz.
El cierre del sistema: cuando una clase A que necesita directa o indirectamente de una clase B forma parte de esta. Un sistema es cerrado si su conjunto de clases contiene todas las clases que necesita la clase raíz.
Para ensamblar un sistema se almacena los textos de clase en archivos, se lo procesa por una herramienta (compilador o intérprete) que necesita la siguiente información:
ü El nombre de la clase raíz.
ü Un conjunto de archivos que contengan el código de las clases que necesita la raíz.
Al exportar atributos de una clase el usuario puede tener ciertos privilegios como:
NIVEL 0: Sin acceso, los clientes no tienen forma de acceder al atributo
NIVEL 1: Solo lectura, accede al atributo pero no tiene derecho a modificarlo.
NIVEL 2: Escritura restringida, permite que los clientes puedan modificar los atributos a través de algoritmos específicos.
NIVEL 3: Escritura protegida, los clientes asignan valores si satisfacen ciertas restricciones puestas por el desarrollador.
NIVEL 4: Sin restricciones, se eliminan todas las restricciones.
Las entidades son nombres que denotan valores durante la ejecución y a su vez están conectadas a objetos, es decir es un atributo de una clase, es un argumento formal de una rutina.
COMO ENCONTRAR LAS CLASES
El objetivo de la metodología orientada a objetos, puesto que la estructura del software O-O es basada en la descomposición en clases es dar alguna recomendación sobra la forma de encontrar la clase.
La búsqueda de clases es la decisión central en la construcción de un sistema de software orientado a objeto.
Uno de los pasos clave para el convencimiento es que como siempre el diseño es una técnica de selección estará definida por dos componentes:
* Que considerar
* Que rechazar
Para encontrar el problema de encontrar las clases, lo mejor puede ser comenzar analizando una técnica muy difundida.
Los Nombres Y Los Verbos
La regla más sencilla para obtener las clases:
* Empezar con el documento de requisito.
* Un diseño orientado a funciones, los cuales corresponden a acciones (hacer esto)
* Un diseño orientado a objetos
Los nombres tomados del documento de requisitos darán lugar a algunas clases del diseño final, pero junto a ellos se incluirán muchas “falsas alarmas”, de las cuales no debería producir clases.
La discusión nos lleva de nuevo a la teoría de los tipos de abstracto de datos, ya que una clase no solo representa objeto físicos en el sentido ingenuo, haciendo que la clase describa un tipo abstracto de dato un conjunto de objeto software caracterizados por operaciones bien definidas y propiedades formales de estas operaciones.
Este principio se refuerza mediante un enfoque de los TAD (que quiere decir el método orientado a objetos) ya que los objetos quedan definidos por lo que podemos hacer por ellos, ya que los dos tipos abstractos es irrelevante para los propósitos del sistema, entonces no debe incluirse en el resultado del análisis independientemente de lo interesante que puedan ser para otros propósito.
Por Alto Clases Importantes
Las causas principales son 3:
- pasar las clases por alto se debe simplemente a la flexibidad y a la ambigüedad del lenguaje humano, ya que las mismas cualidades lo hacen cómodo para una asombrosa gama de aplicaciones, pero de las cuales no son fiables como medio para expresar documentos técnicos precisos.
- otra es que algunas abstracciones cruciales pueden no ser deducibles directamente de los requisitos de un sistema dirigido por paneles no cuales no son explícitamente los conceptos del estado y aplicación.
- la última es la causa más importante de omisión de las clases, ya que comparte por cualquier método que use el documento de requisitos como base del análisis, ya que es una estrategia que pasa por alto la reutilización. Las lecciones más simples se han repetido varias veces:
* no confiar demasiado en un documento de requisitos.
* No confiar para nada en criterios gramaticales.
Una lección menos obvia es la que surgiría de la revisión de las falsas alarmas, ya que se necesitan criterios para encontrar clases y para rechazar clases candidatas.
Una de las formas de ver los peligros es comenzar por las de rechazo, ya que ahí es donde se podrá realizar mejor la búsqueda de las clases centrada en los esfuerzos más productivos.
Una posible excepción seria la de los objetos que representan legítimamente acciones abstractas, incluso ni una clase no tiene todavía todas esas características comprobar que tendría sentido añadirlas posteriormente reforzada la convicción de que se esta tratando con una verdadera abstracción de datos.
Ya que un sistema de software esta basado en un modelo operacional de algún aspecto del mundo externo es operacional por que se usa para generar resultados prácticos y a la vez para insertar nuevos resultados.
PRINCIPIOS DE DISEÑO DE CLASES
Al realizar un proyecto de software se desea que el software crezca con nosotros, un software que se pueda comprender, explicar, reutilizar y en el cual se pueda confiar.
En este capítulo se busca explicar los principios de diseños de clases que han surgido de una extensa practica y han demostrado que producen una gran cavidad y una notable permanencia. Como quiera que se implemente lo que determina el éxito de una clase, es el aspecto que tiene para sus clientes, aquí el hincapié no se hace en la implementación interna de la clase sino en la forma de hacer que su interfaz sea sencillo, fácil de aprender, fácil de recordar y capaz de resistir los ataques de tiempo y el cambio.
Las características que caracterizan a una clase se dividen en órdenes y consultas.
Una orden sirve para modificar objetos. Y la consulta sirve para proporcionar información acerca de los objetos.
Las órdenes se implementan como procedimientos, al momento de desarrollarse estos tienen la función de modificar las cosas a diferencia de las consultas se pueden implementar o bien como atributo. El proceso que debe desarrollar dicha consulta no deberá modificar los objetos. Un cambio efectuando por una función se conoce con el nombre de efecto lateral que indica que no se esta cumpliendo con el propósito de la función.
Si lo que se busca es el perfeccionamiento de las clases se aconseja que no se debe confundir lo que significa una consulta de lo que representa una orden, ni tampoco se debe juntar los dos conceptos puesto implicará que posteriormente se haga más difícil la reutilización de dichas clases y además que estas malas prácticas acarrearan los llamados efectos laterales.
Efecto Lateral.- Una función produce un efecto lateral concreto si su cuerpo contiene algo de lo siguiente:
ü Una introducción de asignación, un intento de asignación, o una introducción de creación cuyo receptor sea un atributo.
ü Una llamada procedimiento.
La transparencia referencial es una importante práctica que dice que “ Una expresión e posee transparencia referencial si es posible intercambiar cualquier sub-expresión con su valor sin modificar el valor de e”.
Es importante mantener la transparencia referencial en las expresiones para que sea posible razonar acerca de nuestro software más adelante.
Al limitarnos a funciones que produzcan efectos laterales, aseguraremos que hablar de funciones dentro del software no traicione el significado de éste término, deberá mantenerse una distinción clara entre órdenes que modifiquen los objetos pero no proporcionen directamente resultados, y, consultas que proporcionan información acerca de los objetos pero no los modifican. Lo que debe significar la regla de “Hacer una pregunta no debería modificar la respuesta.”
La aplicación de una separación estricta entre ordenes y consultas, prohibiendo los efectos laterales abstracto en las funciones, en especialmente adecuada para el desarrollo de grandes sistemas.
Un efecto lateral abstracto es un efecto lateral concreto que puede modificar el valor de una consulta que no sea concreto, este es el concepto que utiliza el principio de separación que prohíbe los efectos laterales abstractos de las funciones.
La sencillez de las características de la interfaz determina de modo fundamental de la facilidad de uso de la clase ¿Cuántos argumentos tienen las características? Cuantos más argumentos haya, mas habrá que recordar. El criterio para el éxito es sencilla: una vez que un usuario potencial de una biblioteca a invertir tiempo necesario para comprender lo que hace la clase, y se decide utilizarla una vez que ha seleccionado el conjunto de características que necesita el ese momento debería ser capaz de aprender esas características al margen de todas las demás.
Tamaño de clase: el enfoque de lista de la compra
Definición del tamaño de una clase
Las clases deben de medirse en relación a las características serán externas e incrementales, donde lo importante es la relación y compatibilidad interna y externa de las clases, y no el numero de iteraciones ni de funciones o atributos. Los Diseñadores de clases suelen tener la tentación de incluir gran cantidad de características, el resultado es una interfaz en que las pocas características usadas comúnmente se pierden en una larga lista de rutinas extrañas.
Consejo de la lista de la compra
Cuando se considere la adición de una nueva característica exportada a una clase hay que observar que la característica tiene que ser relevante para la abstracción de datos representada por la clase, tiene que ser compatible con las otras características de la clase, no tiene que abordar exactamente el mismo objetivo que otras características de la clase, y tiene que mantener el invariante de la clase.
No es el tamaño por si mismo si no la calidad de diseño, es redundante incluir al mismo tiempo las funciones y los procedimientos, en la practica, resulta cómodo tener los dos, al menos por tres razones: como ayuda para el cliente: eficiencia y reutilización.
Estructura activas de datos
Representación de la lista enlazada: la lista enlazada son una representación útil de las estructuras secuenciales, por que facilitan las operaciones de inserción y borrado.
La clase correspondiente, debería ser genérica por cuanto deseamos que la estructura sea aplicable a lista enlazada de cualquier tipo.
Esta representación hace rápida la inserción o al borrado si se tiene una referencia al enlazable que se encuentra inmediatamente a la izquierda de la celda destino de la operación.
Por otra parte la representación de listas enlazada no es especialmente buena para buscar un elemento conocido por su valor o su posición, por contraste, las reparaciones con arrays son buenas para acceder por posición, pero mala para la inserción y borrados.
Clases pasivas
Se debe intentar proveer una interfaz que proporcione a los módulos clientes una lista de primitivas, pero que no les moleste con detalles de implementación tales como la presencia de elementos enlazables.
Tipos abstractos de datos y maquinas abstractas
Dar a las estructuras de datos un estado explicito suele proporcionar unas interfaces sencillas y fáciles de documentar. Podría uno temer que las estructuras resultantes se volvieran menos abstractas, pero esto no es así. Abstracto no quiere decir pasivo, los tipos abstractos de datos es que nuestros objetos deberían de ser conocidos mediante descripciones abstractas de las operaciones aplicables y sus propiedades pero esto no implica tratarlos como si fuesen meros depósitos de datos.
Evolución de clases: La cláusula obsolete:
Todos intentamos hacer que nuestras clases sean perfectas, todas las técnicas de esta discusión tienden a esa meta, aunque solo sea un ideal.
El dilema a la hora de diseñar las clases esta en decidir a quien ira dirigido, a los usuarios actuales o a los usuarios futuros, pues si se diseñan las clases para satisfacer a los usuarios actuales, se corre el peligro de que cuando el tiempo pase, y el sistema necesite evolucionar, los cambios se volverán eventualmente inadmisibles, mientras que si se diseña clases que estén preparadas para cambios futuros, son una alternativa para que el sistema acepte cambios sin problemas, pero afecta a los usuarios actuales al estar usando un sistema que no fue diseñado para dar comodidad al usuario actual.
La respuesta seria utilizar características obsoletas y clases obsoletas. Que no es más que utilizar métodos que den de baja a métodos y característica mientras se pasa a la transición de nuevos métodos dando la posibilidad de que el cambio no sea drástico, y después de un tiempo razonable, todas las clases obsoletas, deberán desaparecer.
