• Clasificación. Se refiere a que los objetos con los mismos atributos y comportamiento –métodos-, son agrupados en clases. Cada objeto perteneciente a una clase, se dice que es una instancia de la clase. Así que una clase, representa a un posible conjunto infinito de objetos individuales. Por ejemplo a todos los alumnos que aparecerán en la lista de calificaciones finales, los clasificamos en la clase Alumno. A todos los amigos que registramos en nuestra agenda, los podemos clasificar en la clase Persona. Notemos que los alumnos también tienen dirección, teléfono y correo electrónico, pero no los agrupamos en la clase Persona ya que estos atributos para el caso de la aplicación de obtener la lista de calificaciones, no se requieren. La pregunta es ¿Los amigos podrían ser alumnos?. Discútelo con tus compañeros del grupo y con tu profesor. La clase describe en una sóla entidad a los atributos y comportamiento –métodos-, de todos los objetos que pertenezcan a ella.
• Polimorfismo. Es una característica de la orientación a objetos, que significa que un mismo método puede tener diferente manera de realizarse, en las diferentes clases que tengamos bajo estudio. Cada objeto perteneciente a una clase, "sabe como" ejecutar sus propios métodos. Cuando programamos orientado a objetos, el lenguaje de programación automáticamente selecciona el método correcto para efectuar una cierta acción o transformación sobre el objeto al que se aplica. Por ejemplo, si tenemos los objetos bicicleta, carro, barco, y les aplicamos la operación Mover, la acción se ejecuta de manera diferente para cada objeto.¿Por qué?. Otro ejemplo típico es el de los objetos de la clase Figura, digamos círculo, rectángulo, triángulo. Apliquémosles la acción de Dibujar, cada uno de ellos tendrá su propio método Dibujar definido, ya que la acción debe implementarse de manera diferente para cada objeto.
• Herencia. Es una de las características que hacen a la oriientación a objetos mas eficiente, mas poderosa. Se refiere a compartir atributos y métodos entre clases, que se relacionan de manera jerárquica. Un ejemplo sería definir la clase Persona con atributos : nombre, edad y sexo. Esta clase se denomina clase base, ya que de aquí podríamos definir otras clases Alumno, Profesor, Empleado, que heredan los atributos y métodos de la clase Persona. A estas 3 clases se les denominan clases derivadas. Entonces, en herencia las clases base proporcionan atributos y métodos a otras clases, las clases derivadas. Para visualizar la herencia, se construyen los árboles de herencia. A cada clase sea base o derivada se denota con un elipse, y la herencia se denota usando una flecha con dirección de la clase derivada hacia la clase base.
Si las clases derivadas tienen los atributos :
• clase Alumno : número de control, calificación,
• clase Profesor : número de tarjeta, grado,
• clase Empleado : salario, nombre del puesto.
Al aplicar la herencia, los objetos de las clases derivadas tendrán ahora además de sus atributos antes enumerados, los atributos que heredan de la clase base Persona.
• clase Alumno : número de control, calificación, nombre, edad, sexo
• clase Profesor : número de tarjeta, grado, nombre, edad, sexo
• clase Empleado : salario, nombre del puesto, nombre, edad, sexo
Lo mismo sucede con los métodos en la clase base Persona, que serían heredados por las clases derivadas Alumno, Profesor, Empleado. Supongamos que la clase Persona tiene definido los métodos AsignaNombre, AsignaEdad, AsignaSexo. Las clases derivadas también heredan a estos métodos, por lo tanto un objeto alumno puede utilizar estos métodos sin necesidad de redefinirlos en la clase Alumno. Por esto, la herencia cuando es utilizada se dice que estamos reusando código. El reuso de código es una característica muy poderosa en la orientación a objetos.
Reconocimiento de objetos y clases en el mundo real y la interacción entre ellos
Ahora que ya conocemos los objetos, sus tipos, sus atributos, su comportamiento –métodos-, sus características, podemos seguir con el reconocimiento de ellos dentro de la especificación de problemas que deseamos solucionar aplicando la orientación a objetos. Veamos algunos ejemplos.
Ejemplo 1.1.1.
En un sistema de cómputo identifica a los objetos y clases que lo conforman. Agrega los atributos y comportamiento para cada clase que hayas reconocido.
Agrega mas objetos, clases, atributos y métodos al ejercicio.
Ejemplo 1.1.2
Identifica los objetos, clases, atributos, métodos para un edificio del Tec Laguna.
Ejemplo 1.1.3
Identifica los objetos, clases, atributos, métodos para un Departamento Académico del Tec Laguna.
Ejercicios propuestos.
1. Encuentra los objetos, clases, atributos y métodos en un juego de futbol.
2. Encuentra los objetos, clases, atributos y métodos en un curso de fundamentos de programación.
3. Encuentra los objetos, clases, atributos y métodos en tú recámara.
4. Encuentra los objetos, clases, atributos y métodos en un carro.
5. Encuentra los objetos, clases, atributos y métodos en una familia.
La interacción entre objetos se efectúa mediante mensajes. Un mensaje se envía a un objeto utilizando un método de la clase. En ocasiones un objeto envía un mensaje a otro objeto de la misma clase o de otra clase, a veces un objeto se envía asimismo el mensaje. Por ejemplo, un chofer –objeto- envía el mensaje Avanzar a un objeto carro. La forma del mensaje sería : carro.Avanza. Vemos que la sintaxis para construir un mensaje está compuesta de 2 partes : el nombre del objeto y el nombre del método. Ambos deben pertenecer a la clase, tanto el objeto como el método.
identificadorDelObjeto.Metodo
Otro mensaje podría ser el que usa el método Arrancar, carro.Arrancar. Los métodos reciben parámetros para caracterizar de manera definida a su acción. Por ejemplo, cuando usamos el mensaje carro.Avanzar, podemos enviar al método
Avanzar un parámetro que indique la velocidad, de manera que ahora escribiríamos el mensaje de la siguiente forma :
carro.Avanzar(primera) ó carro.Avanzar(reversa) ó carro.Avanzar(segunda), y así por el estilo.
Observemos que el parámetro se ha incluido entre paréntesis. Un método que no reciba parámetros, puede escribirse con los paréntesis vacios. Por ejemplo :
carro.Encender()
Cuando escribimos programas orientados a objetos, éstos están compuestos de mensajes.
La abstracción y el encapsulamiento como un proceso natural
Hemos establecido que si usamos la orientación a objetos para enfrentar la solución de un problema, debemos pensar en reconocer objetos, sus atributos y sus métodos, terminando por agrupar a los objetos reconocidos en clases. Al proceso de identificar o reconocer objetos que existen en el contexto de una aplicación –análisis de un problema-, se le denomina proceso de abstracción.
Abstracción. consiste de una examinación colectiva de ciertos aspectos de un problema, con el objetivo de aislar aquellos aspectos que son importantes para algún propósito y suprimir aquellos que no lo son.
Características de la abstracción.
• Para un mismo problema pueden existir diferentes abstracciones, dependiendo del propósito.
• Todas las abstracciones son incompletas e inexactas.
• La abstracción permite limitar el universo de manera que podamos construir modelos.
• No existen abstracciones correctas, sólo existen abstracciones adecuadas o inadecuadas.
Encapsulamiento. este concepto se refiere a lo que ya habíamos comentado anteriormente, acerca de juntar –encapsular- en una sóla entidad –la clase-, tanto atributos como métodos. Sólo imaginate que ves a una muchacha que acapara tu atención, de inmediato ves en ella atributos que ella como objeto perteneciente a la clase Mujer, los contiene. Por ejemplo el color de sus ojos, el color de su tez, el largo de su cabello, la curvatura de sus … brazos, su nombre, su edad. También la clase a la que ella pertenece, encapsula el comportamiento, por ejemplo el Sonreir, Caminar, Observar, Platicar, Estudiar por decir algunos métodos.
Para entablar interacción con ella, deberás pensar –abstraer- mensajes. Por ejemplo, le enviarías para conocer su nombre el mensaje : ellaMujer.ComoTeLLamas. Para saber su edad tal vez deberías usar el mensaje ellaMujer.RetornaTuEdad.
El encapsulamiento tiene otro objetivo en la orientación a objetos, que consiste en la separación de los aspectos externos de un objeto, los cuales son accesibles por otros objetos, de los detalles de implementación interna del objeto, los cuales se ocultan a otros objetos. Esto lo veremos mas tarde cuando enumeremos los beneficios de la orientación a objetos.
Ejercicio propuesto.
1. Construye mensajes para objetos de la clase Alumno, con atributos mencionados en las secciones anteriores.
2. Construye mensajes para objetos de la clase Arbitro de cualquier deporte.
La programación orientada a objetos y la complejidad del software
Primero comentaremos que al referirnos a la programación orientada a objetos, estamos hablando de construir programas cuyas instrucciones manejan objetos de entrada, procesan mensajes que envían a los objetos, de manera que se produzcan objetos de salida.
Software es una palabra en inglés que significa programación, conjunto de programas, de acuerdo al contexto en el que se aplique. En este caso, la complejidad del software se refiere a lo difícil que resulta construir programas orientados a objetos. La programación orientada a objetos viene a sustituir a otra forma de construir programas, que durante mucho tiempo – desde 1973- fue la manera por mucho de escribir programas, la programación orientada a funciones.
Así que la pregunta es, si la programación orientada a objetos disminuye la complejidad del software, es decir, si disminuye la dificultad de construir programas de computadora. Veamos que podemos decir acerca de dicha complejidad.
• En cualquier rama de la ciencia, la complejidad es atacada –disminuida- mediante la construcción de modelos. Cuando aplicamos la orientación a objetos para resolver un problema usando un programa de computadora, nuestros principales esfuerzos son dirigidos hacia la abstracción –limitar el universo– de objetos, las clases a las que pertenecen, identificación de sus atributos y métodos. Este reconocimiento de objetos es requerido para poder obtener los objetos de salida, luego de procesar los objetos de entrada. Al proceso de abstraer los objetos, clases, atributos y métodos tanto de objetos de entrada como de salida, se le conoce como análisis orientado a objetos. Existen algunas metodologías para efectuar el análisis orientado a objetos de un problema. Una de ellas muy popular en estos días, es el uso de diagramas del UML (lenguaje de modelado unificado).
• El hecho de efectuar un buen análisis orientado a objetos, permite un menor tiempo en la implementación de programas orientados a objetos. La orientación a objetos permite una mejor adaptibilidad a los cambios en los requerimientos de un programa, debido a que las clases encapsulan tanto atributos como métodos –operaciones-., de manera que si existiera un cambio en un objeto, como sus atributos y métodos están encapsulados en una clase, los cambios se realizarían sólo sobre atributos y métodos de ese objeto de forma que los efectos colaterales son más fáciles de manejar.
Conceptos del ciclo de vida del software
Hagamos una restricción en las etapas del ciclo de vida del software y revisemos las 4 primeras :
• Especificación de requerimientos.
• Análisis orientado a objetos.
• Diseño orientado a objetos.
• Programación orientada a objetos.
Recordemos que software significa programas, de manera que estamos viendo las etapas que debemos seguir en la construcción de un programa –grandote o chiquito, complejo o fácil-. En este curso de fundamentos de programación, tendremos como principal objetivo aprender a programar, es decir, aprender a construir programas. Por lo tanto, es obvio que debemos de seguir estas etapas cuando construyamos nuestros programas de computadora. Así que no las olvidemos, debemos "talachearlas".
1.4.1. Especificación de requerimientos.
Es la primera etapa en el desarrollo de un programa. generalmente se consideran los siguientes aspectos :
• Ambito del problema.
• ¿Qué es necesario?.
• Contexto de la aplicación.
• ¿Qué se asume por cierto?.
• Necesidades de funcionamiento.
La especificación de requerimientos establece qué es lo vamos a hacer, no cómo lo vamos a hacer. Es un documento escrito en lenguaje natural donde se detallan las necesidades que requerimos cubrir en el programa. No es un documento donde se propone la solución del problema. Los requerimientos son las características que deberá cumplir el programa que construyamos siguiendo las etapas de análisis, diseño e implementación –codificación-.
La especificación de requerimientos es un documento muy importante al desarrollar un programa, ya que al terminar de realizar un programa una medida de la calidad de éste, es comprobar si el programa cumple con cada uno de los requisitos funcionales descritos en la especificación. Un programa tiene calidad si cumple con todos los requerimientos en el documento de especificación.
1.4.2 Análisis orientado a objetos.
Su propósito es modelar el problema a resolver de tal manera que pueda ser entendido. Si no construimos un modelo, entonces el análisis sería una especificación en lenguaje natural con inconsistencias, ambiguedades e incompleto. El modelo en nuestro caso sería un modelo orientado a objetos. Pero, ¿qué es un modelo?.
Modelo. es una abstracción de un problema con el propósito de entenderlo antes de construirlo. Para el caso del desarrollo de un programa orientado a objetos, el modelo especifica gráficamente a los objetos que intervienen en el ámbito de nuestra aplicación, de forma que también indica las clases en las que se agrupan los objetos, los atributos y los métodos para dichos objetos.
Características del análisis orientado a objetos :
• Su salida es un modelo orientado a objetos, incluyendo las clases, atributos y métodos.
• Clarifica los requerimientos definidos en la etapa previa de especificación.
• Proporciona una base formal para el acuerdo (acerca de lo que se requiere), entre el demandante del programa y el desarrollador del programa.
• Su resultado representa la comprensión del sistema que se requiere programar, de manera que sirva como una buena preparación para el diseño del programa.
• El modelo que se construye utiliza notaciones precisas.
• Permite tratar con la complejidad de un problema, de forma que pueda ser programado. En otras palabras reduce la complejidad al escribir un programa.
• El proceso de construir un modelo dentro del análisis, obliga al desarrollador a confrontar lo que no entiende acerca del dominio de una aplicación, al inicio del desarrollo de un programa.
Para construir modelos orientados a objetos existe un conjunto de diagramas que forman parte del Lenguaje para Modelado Unificado (UML en inglés). El UML consiste de un grupo de diagramas que nos ayudan en las diferentes etapas del desarrollo de un programa, no solamente en el análisis.
Los diagramas del UML son los siguientes :
• Diagramas de casos de uso.
• Diagramas de clase.
• Diagramas de actividad.
• Diagramas de secuencia.
• Diagramas de estado.
• Diagramas de componentes y de puesta en uso.
1.4.3 Diseño orientado a objetos.
Una vez que hemos analizado un problema con el fin de construir un programa que lo soluciones, seguimos con la etapa del diseño. Durante la etapa del diseño se especifica el CÓMO se va a construir el programa, a diferencia del análisis en donde se especifica el QUÉ es necesario hacer para construirlo.
En la etapa del diseño se decide la ARQUITECTUIRA DEL PROGRAMA, es decir su estructura y estilo. Esta arquitectura proporciona el contexto que servirá de base para efectuar decisiones mas detalladas en posteriores estados del diseño. La arquitectura del programa consiste en organizar el programa en módulos que contienen objetos. A este proceso se le denomina modularización.
Cada módulo contiene mensajes -identidicadorDeObjeto.Metodo()- entre objetos que pertenecen o no al módulo. Este conjunto de mensajes en que consiste el módulo, efectúan tareas simples, lógicas y completas. A estas tareas se les denominan tareas cohesivas.
Los diagramas de casos de uso del UML son utilizados en la etapa del diseño, representando una parte fundamental de base para conseguir la modularización del programa. En los diagramas de casos de uso se especifican las tareas que se deben realizar en cada módulo del programa. Los objetos que intervienen ya han sido previamente modelados en el análisis mediante la utilización de los diagramas de clase.
Las transformaciones de los objetos se detallan en los diagramas de estado, las cuales son descritas de manera íntegra en la etapa del diseño.
Otras fases en el diseño de objetos son las definiciones de las interfases y algoritmos utilizados para la implementación de los diferentes métodos y tareas previamente analizadas y descritas. Los algoritmos son escritos en lenguaje natural en neustro caso el español. Los tipos de datos empleados en la definición de las variables que intervienen en los algoritmos, se les llama tipos de datos abstractos. La etapa del diseño orientado a objetos también añade objetos internos para completar la implementación del programa, además de emplear refinamientos sucesivos de manera que se eficienticen las estrucuras de los objetos –atributos y métodos- y los algorimtos en cada módulo en los que se ha descompuesto el programa.
Los diagramas del UML que son fundamentales en la etapa de diseño para construcción de algoritmos y refinación de las clases, son los diagramas de actividad y diagramas de secuencia. estos 2 diagramas se relacionan fuertemente con las acciones que producen los cambios en los objetos definidos en los diagramas de estados del UML utilizados en la etapa del análisis.
1.4.4 Programación orientada a objetos.
Esta etapa es llamada de varias maneras : Implementación ó Codificación. En la etapa de diseño los algoritmos que realizan las tareas de cada módulo en que se dividió el programa, se escriben en lenguaje natural –para nosotros el español-. En cambio, en la etapa de implementación o codificación los algoritmos –programas- que cumplen con las tareas de cada módulo, son escritos –codificados- en el lenguaje de programación seleccionado. El lenguaje de programación que nosotros usaremos es el lenguaje C#.
Aquí los algoritmos de la etapa de diseño son codificados en sentencias propias del lenguaje de programación. Un lenguaje de programación tiene tipos predefinidos de datos, tiene sus sentencias y clases propias, de manera que es relativamente fácil definir clases y objetos que previamente habíamos abstraido en las etapas de análisis y diseño.
En el lenguaje C# una clase se define utilizando la palabra reservada class. Los atributos y métodos se encierran entre los caracteres { y }. Después de la palabra reservada class se agrega el nombre de la clase.
class Alumno
{
// definición de atributos
// definición de métodos
}
Los atributos de un objeto que pertenece a una clase tienen siempre un tipo. Por ejemplo, la calificación de un alumno es un entero de 0 a 100, así que el tipo del atributo calificacion es de tipo entero –int en C#-. El nombre del alumno es una cadena de caracteres de manera que el tipo del atributo nombre es tipo cadena –string en C#-. Los tipos int y string son tipos de datos predefinidos en C#. Los tipos predefinidos son los tipos de datos básicos que un lenguaje tiene integrados en su ambiente de desarrollo, para que el programador los utilice sin restricción alguna.
Elementos primordiales en el modelo de objetos
En las secciones anteriores ya hemos visto los conceptos de :
• Abstración, la cual consiste de una examinación colectiva de ciertos aspectos de un problema, con el objetivo de aislar aquellos aspectos que son importantes para algún propósito y suprimir aquellos que no lo son. Se utiliza para abstraer objetos, sus atributos y métodos, además de las clases a las que pertenecen los objetos.
• Encapsulamiento, que consiste en la separación de los aspectos externos de un objeto, los cuales son accesibles por otros objetos, de los detalles de implementación interna del objeto, los cuales se ocultan a otros objetos.
• Modularidad, consiste en organizar el programa en módulos que contienen objetos pertenecientes a determinadas clases, cuya interacción entre ellos desarrollan una tarea específica, lógica y completa. La suma de estos módulos y su correspondiente tarea que realizan, son la resolución del problema.
• Jerarquía y herencia, se refieren a compartir atributos y métodos entre clases, que se relacionan de manera jerárquica.
• Polimorfismo, es una característica de la orientación a objetos, que significa que un mismo método puede tener diferente manera de realizarse, en las diferentes clases que tengamos bajo estudio
Existe otro concepto que es muy importante : el ocultamiento de atributos. El ocultamiento de atributos está relacionado al concepto de encapsulamiento. Dado que en la clase es donde se concentran en una sóla entidad a los atributos y a los métodos, podríamos pensar ¿para qué se hace esto?.
Una regla de oro en la programación orientada a objetos es ocultar a los atributos del mundo externo a la clase, es decir, ocultar los atributos a otros objetos que no pertenecen a la clase, de manera que para accederlos ya sea para lectura, ya sea para escritura, el acceso sólo puede efectuarse mediante los métodos de la clase. A los métodos de la clase a menudo se les denomina interfase de la clase –comportamiento-. Un programador deberá saber los métodos definidos en la clase para poder acceder a los atributos de los objetos pertenecientes a esa clase. Por ejemplo, si queremos modificar la calificación de un alumno, deberíamos utilizar el método AsignarCalificacion(califNueva) que toma al parámetro califNueva y lo asigna al atributo calificacion del objeto involucrado en el mensaje. Digamos que el objeto le hemos llamado oAlumno1, entonces el mensaje sería :
oAlumno1.AsignarCalificacion(100) ó
oAlumno1.AsignarCalificacion(califNueva)
En el primer mensaje, se asigna un 100 al alumno, mientras que en el segundo mensaje se asigna el valor del parámetro
califNueva al alumno.
Historia de los paradigmas en el desarrollo de software
Sólo me referiré al paradigma de la orientación a funciones, ya que antecede a la orientación a objetos en uso y popularidad. Antes de escribir sobre la orientación a funciones, veremos el concepto de paradigma.
Paradigma.- representa una forma de abstraer los elementos que se encuentran en el contexto de un problema y que enfocándonos a ellos –analizándolos-, nos ayudan a construir el software –programa- que requerimos.
Desde 1973 en que Edgser Dijkstra contribuye con sus principios de programación estructurada, las metodologías propuestas en el mundo de la computación para desarrollo de programas que incluyen análisis y diseño, todas se basaron en la orientación a funciones.
Orientación a funciones. indica que debemos descomponer funcionalmente un problema, de manera que obtengamos módulos que efectúen una función que puede ser desde compleja hasta simple. La modularización que conlleva la descomposición en funciones del problema a resolver, se debe llevar a cabo hasta obtener funciones simples, lógicas y completas. Una función con estas características es llamada función cohesiva.
Por ejemplo, un profesor requiere de obtener una lista de cada uno de sus grupos donde se indique la clave del grupo, el horario, el periodo, y el número de control, el nombre, y la calificación final de cada uno de los alumnos del grupo que se trate, además requiere del promedio del grupo, del número de alumnos aprobados y del número de alumnos reprobados..
La orientación a funciones nos indica que debemos descomponer en funciones este problema, que sumadas lo resuelvan. Entonces debemos efectuar el proceso de abstracción de dichas funciones, ordenando la ejecución de cada función de manera que se eviten indeterminaciones en los datos. La indeterminación de los datos es otro concepto manejado en la programación estructurada, consiste de evitar utilizar datos que previamente no hayan sido asignados o leídos. Para nuestro ejemplo, una función sería la visualizar los datos de los alumnos. Digamos que los datos de los alumnos del grupo FUNDAMENTOS DE PROGRAMACION no han sido leidos aún, ¿que salida en la visualización podríamos esperar?. Discútelo con tu profesor y tus compañeros. Es claro que estaríamos en un caso de indeterminación de datos, ¿de cuáles datos? , pues del número de control, nombre y calificación final de los alumnos del grupo FUNDAMENTOS DE PROGRAMACION. Una abstracción de las funciones que podrían resolver el problema del profesor son :
• Leer datos de los grupos.
• Leer datos de los alumnos de cada grupo
• Calcular promedio de cada grupo
• Calcular número de aprobados y de reprobados.
• Visualizar la lista del grupo seleccionado.
Generalmente en la orientación a funciones, la descomposición funcional es mostrada con rectángulos que denotan a las funciones de manera jerárquica.
Para el punto de vista de un programador esta descomposición funcional –modularización- podría estar compuesta de sólo funciones cohesivas. Es decir, los módulos están tan obvios para él que ya no necesita seguir descomponiendo a ninguna de ellas. Otro programador podría no coincidir con este punto de vista y tratará de seguir descomponiendo funcionalmente, al módulo que el crea que la tarea que realiza se compone de otras tantas funciones.
Por ejemplo, digamos que el módulo LEER DATOS DE LOS ALUMNOS DE CADA GRUPO requiere de una mayor modularización, según lo indicamos enseguida :
• Leer la clave del grupo
• Validar que el grupo haya sido dado de alta previamente.
• Leer los datos de los alumnos del grupo seleccionado. El diagrama de la descomposición funcional cambiaría a :
Estos refinamientos se realizan hasta que el analista o programador quede satisfecho con su modularización del problema.
Beneficios del modelo de objetos y de la P.O.O. sobre otros paradigmas
Los beneficios del desarrollo orientado a objetos son sus características que hemos ya abordado, tales como :
• Clasificación.
• Herencia.
• Polimorfismo.
• Encapsulamiento.
• Ocultamiento.
En cuanto a la programación orientada a objetos podríamos enumerar :
• Sobrecarga de operadores y métodos.
• Constructores y destructores.
• Manejo de excepciones.
• Atributos y métodos estáticos.
• Recolectores de basura – Liberadores de memoria -. Los beneficios en cuanto a desarrollo de sistemas :
• Facilidad en la traducción de requerimiento de negocios a módulos de código. Lo anterior es debido a que la orientación a objetos nos permite modelar nuestras aplicaciones basados en ideas de objetos del mundo real, de manera que frecuentemente identificamos una relación directa entre gente, cosas, conceptos, y las clases equivalentes que las modelan –representan-. Estas clases tienen las mismas propiedades y comportamientos tal como los conceptos en el mundo real que ellas representan, lo cual ayuda a identificar mas fácilmente –rápidamente- el código necesario a escribir, asi como las diferentes partes de la aplicación que requieren de interactuar entre ellas.
• Otro beneficio es el resuso de código. Frecuentemente necesitamos de los mismos tipos de dato en diferentes sitios de la misma aplicación. Por ejemplo, una aplicación referente a un hospital que requiera administrar los registros de sus pacientes, definitivamente necesita de una clase Persona. Existe además determinada gente involucrada en el cuidado de un paciente, como son los doctores, las enfermeras, administradores del hospital, gente de atención de asegurados, entre otros. Si definimos una clase genérica llamada Persona, que contenga todos las propiedades y métodos comunes a toda esta gente, podríamos tener una buena cantidad de código reusable que no siempre es posible usando la orientación a objetos. Ahora imaginemos que podemos usar esta clase Persona en otros proyectos, el beneficio del reuso de código se extiende a otras dimensiones.
• La modularidad de las clases es otro beneficio. Si descubriéramos un error en la clase Persona o si desearamos agregar o cambiar los métodos en la clase, nuestro esfuerzo lo dirigimos claramente a la clase y objetos de la clase Persona. Toda la clase generalmente está en un solo módulo : un archivo. Cualquier proceso de la aplicación que tenga relación con la clase Persona será afectado inmediatamente por los cambios en ella. La identificación de estos procesos es fácil, de manera que los cambios necesarios los localizamos de forma simple, así que la búsqueda del código que debamos actualizar se reduce a una tarea sin muchas penas.
Autor:
FRANCISCO RÍOS ACOSTA
Instituto Tecnológico de la Laguna Blvd. Revolución y calzada Cuauhtémoc s/n Colonia centro
Torreón, Coah; México
| Página siguiente |