Conceptos del paradigma orientado a objetos
Anuncio
Conceptos del paradigma orientado a objetos El desarrollo de proyectos software a lo largo del tiempo ha sufrido una evolución desde los primeros sistemas de cálculo, implementados en grandes computadoras simplemente ayudados mediante unas tarjetas perforadas donde los programadores escribían sus algoritmos de control, hasta la revolución de los sistemas de información e internet. Han existido dos grandes cambios desde aquellos sistemas meramente algorítmicos donde todo el esfuerzo de desarrollo se centraba en la escritura de programas que realizaran algún tipo de cálculo. El primero de ellos es la aparición del modelo relacional, un modelo con fuerte base matemática que supuso el desarrollo las bases de datos y propició la aparición de los grandes sistemas de información. El segundo cambio es sobre los lenguajes de programación, la aparición de los Lenguajes Orientados a Objetos (aunque los primero lenguajes con características de orientación a objetos aparecieron en la década de los setenta, por ejemplo Simula 67) supuso una revolución en la industria software. El problema entonces radicaba en poder sacarle partido a los lenguajes orientados a objetos por lo que aparecieron numerosas metodologías para el diseño orientado objetos, hubo un momento en el que se podía decir que el concepto de orientación a objetos estaba “de moda” y todo era orientado a objetos, cuando realmente lo que ocurría es que las grandes empresas que proporcionaban los compiladores y lenguajes de programación “lavaban la cara" a sus compiladores, sacaban nuevas versiones que adoptaran alguno de los conceptos de orientación a objetos y los vendían como orientados a objetos. En la actualidad el desarrollo orientado a objetos se considera uno de los más poderosos modelos desarrollados. Para poner un poco de orden, sobre todo en lo que respecta a la modelización de sistemas software, aparece UML (Unified Modeling Languaje, Lenguaje Unificado de Modelado) que pretende unificar las tres metodologías más difundidas (OMT, Bootch y OOSE) e intentar que la industria software termine su maduración como Ingeniería. Modelado Para producir software que cumpla su propósito hay que obtener los requisitos del sistema, esto se consigue conociendo de una forma disciplinada a los usuarios y haciéndolos participar de manera activa para que no queden “cabos sueltos”. Para conseguir un software de calidad, que sea duradero y fácil de mantener hay que idear una sólida base arquitectónica que sea flexible al cambio. Para desarrollar software, rápida y eficientemente, minimizando el trabajo de recodificación y evitando crear miles de líneas de código inútil hay que disponer, además de la gente y las herramientas necesarias, de un enfoque apropiado. El modelado es la espina dorsal del desarrollo software de calidad. Se construyen modelos para poder comunicarnos con otros, para explicar el comportamiento del sistema a MC Beatriz Beltrán Martínez / MC Miguel Rodríguez Hernández desarrollar, para comprender, nosotros mismos, mejor ese sistema, para controlar el riesgo y en definitiva para poder atacar problemas que sin el modelado su resolución sería imposible, tanto desde el punto de vista de los desarrolladores como desde el punto de vista del cliente, el cual, si finalmente se le entrega el producto del desarrollo, se encontrará con infinidades de problemas, desde que no se cumplen las especificaciones hasta fallos que dejan inutilizado el sistema. El modelado, o modelo de objetos, describe los conceptos principales de la orientación a objetos: las estructuras estáticas y sus relaciones. Las principales estructuras estáticas son los objetos y clases, los cuales están compuestos de atributos y operaciones, mientras que las principales relaciones entre objetos y entre clases corresponden a las ligas y asociaciones, respectivamente. A través del modelado conseguimos cuatro objetivos: Los modelos nos ayudan a visualizar cómo es o queremos que sea un sistema. Los modelos nos permiten especificar la estructura o el comportamiento de un sistema. Los modelos nos proporcionan plantillas que nos guían en la construcción de un sistema. Los modelos documentan las decisiones que hemos adoptado. Orientación a Objetos La programación estructurada tradicional se basa fundamentalmente en la ecuación de Wirth: Algoritmos + Estructuras de Datos = Programas Esta ecuación significa que en la programación estructurada u orientada a procedimientos los datos y el código se trata por separado y lo único se realiza son funciones o procedimientos que tratan esos datos y los van pasando de unos a otros hasta que se obtiene el resultado que se desea. La Programación Orientada a Objetos, POO (OOP, Object Oriented Programming, en inglés), es una técnica de programación cuyo soporte fundamental es el objeto. Un objeto es una extensión de un Tipo Abstracto de Datos (TAD), concepto ampliamente utilizado desde la década de los setenta. Un TAD es un tipo definido por el usuario, que encapsula un conjunto de datos y las operaciones sobre estos datos. A la hora de definir TAD’s (u objetos) se usa un concepto que nos ayuda a representar la realidad mediante modelos computacionales, la abstracción, que es un proceso mental por el que se evitan los detalles para centrarse en las cosas más genéricas de manera que se facilite su comprensión. De hecho la abstracción no sólo se utiliza en la informática, un arquitecto al que le han encargado realizar los planos de un edificio no comenzará por diseñar los planos con máximo nivel de detalle, sino que comenzará a realzar ciertos esbozos en un papel para posteriormente ir refinando. Por supuesto que cuando está realizando los esbozos no se preocupa de por dónde van a ir las líneas MC Beatriz Beltrán Martínez / MC Miguel Rodríguez Hernández eléctricas ni las tuberías de saneamiento, abstrae esos detalles para atacarlos posteriormente cuando tenga clara la estructura del edificio. La diferencia entre el concepto de TAD y el de objeto radica en que además del proceso de abstracción que se utiliza para su definición, existen otros dos con los que se forma el núcleo principal de la programación orientada a objetos, estos son la herencia y el polimorfismo. Ventajas de la orientación a objetos Las ventajas más importantes de la programación orientada a objetos son las siguientes: Mantenibilidad (facilidad de mantenimiento). Los programas que se diseñan utilizando el concepto de orientación a objetos son más fáciles de leer y comprender y el control de la complejidad del programa se consigue gracias a la ocultación de la información que permite dejar visibles sólo los detalles más relevantes. Modificabilidad (facilidad para modificar los programas). Se pueden realizar añadidos o supresiones a programas simplemente añadiendo, suprimiendo o modificando objetos. Reusabilidad. Los objetos, si han sido correctamente diseñados, se pueden usar numerosas veces y en distintos proyectos. Fiabilidad. Los programas orientados a objetos suelen ser más fiables ya que se basan en el uso de objetos ya definidos que están ampliamente testados. Estas ventajas son directas a los programadores. Estos, se podría decir, que son los ejecutores de un determinado proyecto software. Pero la orientación a objetos no sólo reporta beneficios a los programadores. En las etapas de análisis, previas a la codificación, el utilizar un modelado orientado a objetos reporta grandes beneficios ya estas mismas ventajas son aplicables a todas las fases del ciclo de vida de un proyecto software. La tendencia actual es a tratar temas conceptuales de primer plano (o sea, en las fases de análisis) y no temas finales de implementación. Los fallos durante la etapa de implementación son más difíciles de corregir y más costosos que si se dan en las etapas previas. El modelado orientado a objetos tiende al refinamiento sucesivo de manera que se llega a la etapa de implementación con un diseño lo suficientemente explícito para que no existan casos inesperados y todo independientemente del lenguaje de programación (salvo en etapas muy próximas a la implementación donde no hay más remedio que contar con el soporte que se recibe del lenguaje elegido). El desarrollo orientado a objetos es más una manera de pensar y no una técnica de programación. Conceptos básicos de la orientación a objeto Como ya hemos dicho la orientación a objetos se basa en conceptos como clase, objeto, herencia y polimorfismo, pero también en otros muchos, los cuales se explican a detalle a continuación. MC Beatriz Beltrán Martínez / MC Miguel Rodríguez Hernández 1. Abstracción La abstracción se enfoca en la vista externa del objeto y sirve para separar el comportamiento esencial del objeto de su implementación. La abstracción se enfoca sobre las características importantes de algún objeto, relativo a la perspectiva de que observa. Gracias a la abstracción podemos representar las características esenciales de un objeto sin preocuparnos de las restantes características (no esenciales). La abstracción se centra en la vista externa de un objeto, de modo que sirva para separar el comportamiento esencial de un objeto de su implementación. En el sentido más general, una abstracción es una representación concisa de una idea o de un objeto complicado. En un sentido más específico, la abstracción localiza y oculta los detalles de un modelo o diseño para generar y manipular objetos. Una abstracción tiene un significado más general que la encapsulación, pudiendo hablar de abstracción de datos en lugar de encapsulación de datos. La abstracción es una estrategia de resolución de problemas en la cual el programador se concentra en resolver una parte del problema ignorando completamente los detalles sobre cómo se resuelven el resto de las partes. En este proceso de abstracción se considera que el resto de las partes ya han sido resueltas y por lo tanto pueden servir de apoyo para resolver la parte que recibe la atención. Imaginemos que se quiere aplicar la abstracción a las Computadoras, las personas que compran una, no requieren saber de su funcionamiento interno para poder utilizarla. MC Beatriz Beltrán Martínez / MC Miguel Rodríguez Hernández Si ahora, la abstracción la aplicamos a los Automóviles, sucede algo muy similar, la persona que adquiere uno, no requiere saber cómo funciona de manera interna, solo tiene que saber manejar y los servicios básicos (gasolina, llevarlo a mantenimiento, agua, etc.). 2. Clase y objeto Los objetos son las entidades básicas del modelo de objeto. La palabra objeto proviene del latín objectus, donde ob significa hacía, y jacere significa arrojar; o sea que teóricamente un objeto es cualquier cosa que se pueda arrojar. Ejemplo: Una pelota o un libro se pueden arrojar, por lo tanto estos son objetos. Por otro lado, un avión o un elefante también se consideran objetos, aunque sean bastante pesados para ser arrojados. Los objetos son más que simples cosas que se puedan arrojar, son conceptos pudiendo ser abstractos o concretos. Ejemplo: Una mesa es un objeto concreto, mientras que un viaje es un objeto abstracto. Los objetos corresponden por lo general a sustantivos, pero no a gerundios. Ejemplo: Mesa y viaje son ambos sustantivos y por lo tanto objetos. Trabajando y estudiando son gerundios por lo cual no se consideran objetos. Cualquier cosa que incorpore una estructura y un comportamiento se le puede considerar como un objeto. Ejemplo: Una pelota es sólida y redonda y se le puede arrojar o atrapar. Un libro es rectangular y sólido y se le puede abrir, cerrar, y leer. Un objeto debe tener una identidad coherente, al que se le puede asignar un nombre razonable y conciso. Ejemplo: Se consideran manzanas todas las frutas con un sabor, textura, y forma similar. La existencia de un objeto depende del contexto del problema. Lo que puede ser un objeto apropiado en una aplicación puede no ser apropiado en otra, y al revés. Por lo general, existen muchos objetos en una aplicación, y parte del desafío es encontrarlos. Ejemplo: La temperatura se puede considerar un objeto abstracto, teniendo propiedades tales como el valor de la temperatura y el tipo de la escala en que se mide MC Beatriz Beltrán Martínez / MC Miguel Rodríguez Hernández (Celsius o Fahrenheit). Por otro lado, si hablamos de un termómetro, la temperatura pasa a ser una propiedad del termómetro. Los objetos se definen según el contexto de la aplicación. Ejemplo: Una persona llamada Juan Pérez se considera un objeto para una compañía, mientras que para un laboratorio el hígado de Juan Pérez es un objeto. Una universidad como la BUAP se considera un objeto, mientras que dentro de la BUAP los objetos serían las aulas, los estudiantes y los profesores. Los objetos deben ser entidades que existen de forma independiente. Se debe distinguir entre los objetos, los cuales contienen características o propiedades, y las propias características. Ejemplo: El color y la forma de una manzana no se consideran propiamente objetos, sino propiedades del objeto manzana. El nombre de una persona se considera una propiedad de la persona. Un grupo de cosas puede ser un objeto si existe como una entidad independiente. Ejemplo: Un automóvil se considera un objeto el cual consiste de varias partes, como el motor y la carrocería. Los objetos deben tener nombres en singular, y no en plural. Ejemplo: Un automóvil es un objeto, automóviles son simplemente muchos objetos y no un solo objeto. Parte de una cosa puede considerarse un objeto. Ejemplo: La rueda, la cual es parte del automóvil, se puede considerar un objeto. Por otro lado, el lado izquierdo del automóvil sería un mal objeto. Los objetos deben tener nombren razonables y concisos para evitar la construcción de objetos que no tengan una identidad coherente. Ejemplo: Datos o información no son nombres concisos de objetos. Por otro lado, un estudiante es un objeto, ya que contiene propiedades como el número de matrícula y nombre del estudiante, además incluye un comportamiento tal como ir a clases, presentar exámenes, y graduarse. Todos los estudiantes cuyos apellidos comiencen con "A" sería un mal objeto ya que el nombre del objeto no es conciso. MC Beatriz Beltrán Martínez / MC Miguel Rodríguez Hernández El objeto integra una estructura de datos (atributos) y un comportamiento (operaciones). Una clase describe un grupo de objetos con estructura y comportamiento común. (Clase y tipo no son necesariamente equivalentes, tipo se define por las manipulaciones que se le puede dar a un objeto dentro de un lenguaje y clase involucra una estructura, pudiendo corresponder a una implementación particular de un tipo.) Las estructuras o propiedades de la clase se conocen como atributos y el comportamiento como operaciones. Una clase define uno o más objetos, donde los objetos pertenecen a la clase, teniendo características comunes. Ejemplo: Juan Pérez y María López se consideran miembros de la clase persona, donde todas las personas tienen una edad y un nombre. La BUAP y la UDLA pertenecen a la clase universidad, donde todas las universidades tienen una dirección y un grado máximo. Chrysler y Microsoft pertenecen a la clase compañía, donde todas las compañías tienen una dirección, un número de empleados, y una ganancia al año. Una clase se considera un "molde" del cual se crean múltiples objetos. Ejemplo: La clase es como un molde de una cerámica de la cual se pueden crear múltiples cerámicas, todas con exactamente las mismas características. Para modificar las cerámicas hay que primero construir un nuevo molde. Al definir múltiples objetos en clases se logra una abstracción del problema. Se generaliza de los casos específicos definiciones comunes, como nombres de la clase, atributos, y operaciones. Ejemplo: Los objetos impresora a láser, impresora de burbuja, e impresora de punto son todos objetos que pertenecen a la clase impresora. Una clase como la hemos definido se conoce también como clase básica. MC Beatriz Beltrán Martínez / MC Miguel Rodríguez Hernández Todos los objetos son instancias de una clase y la clase de un objeto es una propiedad implícita del objeto. Cada objeto conoce su clase y la mayoría de los lenguajes de programación orientados al objeto pueden determinar la clase de un objeto en tiempo de ejecución. La agrupación en clases de los objetos permite la abstracción de un problema. Las definiciones comunes, tales como nombres de clases y de atributos se almacenan una vez por cada clase. Las operaciones se escriben una vez para cada clase: reutilización de código. Imaginemos que queremos aplicar la abstracción a las Aves: El objeto serían el pájaro, y sus características por ejemplo, serían pico, alas, plumas y patas. El comportamiento sería volar, parar, etc. 3. Relación entre clases Las relaciones entre clases juegan un papel importante en el modelo de objetos. Las clases, al igual que los objetos, no existen de modo aislado. Por esta razón existirán relaciones entre clases y entre objetos. Las relaciones entre clases, se deben a dos razones. La primera, una relación entre clases puede indicar algún tipo de compartición (por ejemplo margaritas y rosas son ambas tipos de flores). Segunda, una relación entre clases puede indicar algún tipo de conexión semántica; por ejemplo, las rosas rojas y amarillas, son más parecidas entre sí que las margaritas y las rosas. Los tres grandes tipos de relaciones entre clases son: Generalización / especialización (es-un). Agregación (todo / parte). Asociación. Generalización / Especialización (is-a / es-un) Las clases se pueden organizar en estructuras jerárquicas. La herencia es una relación entre clases donde una clase comparte la estructura o comportamiento, definida en una (herencia simple) o más clases (herencia múltiple). Se denomina superclase a la clase de la cual heredan otras clases. De modo similar, una clase que hereda de una o más clases se denomina subclase. Una subclase heredará atributos de una superclase en el árbol jerárquico. La herencia, por consiguiente, define un tipo de jerarquía entre clases, en las que una subclase hereda de una o más superclases. MC Beatriz Beltrán Martínez / MC Miguel Rodríguez Hernández En la siguiente imagen, se ilustra la jerarquía de la clase Animal, con dos subclases que heredan de la superclase. Animal Mamífero Perro Gato Reptil Zorro Cocodrilo Serpiente Herencia es la propiedad por la cual instancias de una clase hija (o subclase) puede acceder tanto a datos como a comportamientos (métodos) asociados con una clase padre (o superclase). La herencia siempre es transitiva, de modo que una clase puede heredar características de superclases de nivel superior. Esto es, si la clase perro es una subclase de mamífero y de animal. Una vez que la jerarquía se ha establecido es fácil extenderla. Para describir sus diferencias a partir de un concepto de una jerarquía existente. La herencia significa que el comportamiento y los datos asociados con las clases hijas son siempre una extensión de las propiedades asociadas con las clases padres. Una subclase debe tener todas las propiedades de la clase padre y otras. Una superclase representa una generalización de las subclases. De igual modo, una subclase de una clase dada representa una especialización de la clase superior. La clase derivada es-un tipo de la clase base o superclase. En el modelado orientado a objetos es útil introducir clases en un cierto nivel que puede no existir en la realidad, pero que son construcciones conceptuales útiles. Estas clases se conocen como clases abstractas y su propiedad fundamental es que no se pueden crear instancias de ellas. Ejemplos de una clase abstracta es FiguraGeometrica, ya que se sabe que toda figura geométrica tiene un área y un perímetro, pero hasta no saber que figura es, no se pueden calcular. La generalización, en esencia, es una abstracción en que un conjunto de objetos de propiedades similares se representa mediante un objeto genérico. El método usual para construir relaciones entre clases es definir generalizaciones buscando propiedades y funciones de un grupo de tipos de objetos similares, que se agrupan. MC Beatriz Beltrán Martínez / MC Miguel Rodríguez Hernández FiguraGeo métrica Cuadrado Circulo Triangulo Agregación Una agregación es una relación que representa a los objetos compuestos. Un objeto es compuesto si se compone a su vez de otros objetos. Una casa se compone de habitaciones, tejados, suelos, ventanas, etc. Una habitación a su vez, se compone de paredes, techos, suelo, ventanas y puertas. Casa tiene tiene tiene Habitación Tejados tiene tiene tiene Puertas Ventanas tiene Paredes La agregación de objetos permite describir modelos del mundo real que se componen de otros modelos, que a su vez se componen de otros modelos. La agregación es un concepto que se utiliza para expresar tipo de relaciones entre objetos parte-de (part-of) o tiene-un (has-a). El objeto componente, también a veces denominado continente o contenedor, es un objeto agregado que se compone de múltiples objetos. La agregación es una forma específica de asociación y no un comportamiento independiente, que añade significados o connotaciones semánticas en ciertos casos. Dos objetos forman un agregado, o existe entre ellos una relación de agregación, si existe ente ellos una relación todo-parte, continente-contenido. La agregación puede ser de dos tipos, por contenido físico o por contenido por referencia o conceptual. MC Beatriz Beltrán Martínez / MC Miguel Rodríguez Hernández La agregación por contenido físico o por valor implica que un objeto contenido no existe independientemente del objeto contenedor. La vida de ambos objetos está íntimamente relacionada. Cuando se crea un sintagma de la clase contenedor o1, se crea una instancia de la clase contenida o2. Cuando se destruye el objeto o1, se destruye el objeto o2. El objeto agregado Coche, se compone de un motor, una transmisión, un chasis, etc., que son a su vez parte-de coche, siendo una agregación con contenido físico. Coche Parte-de Parte-de Motor Transmisión Parte-de Parte-de Chasis Puerta La agregación no implica no implica siempre contenido físico, como en el caso de Coche, sino que puede implicar simplemente relaciones conceptuales. Así un Edificio puede componer de Divisiones, que a su vez constan de Oficinas, o bien una Compañía consta de varios Departamentos y cada Departamento consta de varias secciones. Compañía Edificio Departamento División Sección Oficina En la agregación por referencia, conceptual o sin contenido físico no existe fuerte dependencia entre objetos de las clases continente / contenido y no están acoplados entre ellos. Eso significa que se pueden crear y destruir instancias de clase independiente. MC Beatriz Beltrán Martínez / MC Miguel Rodríguez Hernández Asociación Una asociación representa una dependencia semántica entre clases e implica la dirección de esta dependencia. En general, las asociaciones son bidireccionales, aunque pudiesen ser unidireccionales si así se indica expresamente. Una relación de asociación define una relación de pertenencia. Para encontrar relaciones de asociación es preciso buscar frases tales como “pertenece a”, “es miembro de”, “está asociado con”, “trabaja para”, etc. Juan Pérez Trabaja-para IBM Las asociaciones pueden ser unitarias, binarias, ternarias o de cualquier otro orden, aunque la mayoría serán binarias. Una propiedad importante intrínseca a la relación de asociación o multiplicidad es la cardinalidad o multiplicidad. La multiplicidad es la propiedad que expresa el número de instancias de una clase que se asocian o conectan con instancias de la clase asociada. Existen tres tipos de multiplicidad o cardinalidad: Una a una Una a muchas Muchas a muchas Una relación una a una implica una relación estrecha entre objetos. Por ejemplo, una relación entre una clase venta de un producto y la clase operaciónTD que representa la operación o pago de la venta mediante una tarjeta de crédito. Cada venta se corresponde con una operación de una tarjeta de crédito y a la inversa. Otro ejemplo es la relación entre País y Capital. Un país tiene una capital y sólo una, y una ciudad que es capital de un país sólo pertenece a un país. Una relación una a muchas se puede ver entre las clases País y Ciudad. Un país tiene muchas ciudades, mientras que una ciudad sólo pertenece a un país. Otro ejemplo se da entre la clase Línea, Circunferencia, o en general Figura y la clase Punto. Cualquier figura puede tener muchos puntos, y un punto se asocia a una figura. Las clases Ventas y Artículo se enlazan también por una relación una a muchas. Una venta puede constar de muchos artículos. Por último, la multiplicidad muchas a muchas, implica que una instancia de una clase puede corresponder con muchas instancias de otra clase, y viceversa. Las clases Estudiante y Asignatura están relacionadas con asociaciones de multiplicidad muchas a muchas. Un estudiante puede estar inscrito en muchas asignaturas, y en una asignatura determinada pueden estar inscritos muchos alumnos. MC Beatriz Beltrán Martínez / MC Miguel Rodríguez Hernández Las relaciones de multiplicidad o cardinalidad se indican de muy diversas formas, según sea la metodología de análisis y diseño orientada a objetos que se utilice. Las notaciones más usuales son: 1..n, 1-m una a muchas 1 n 0 1 n m una a muchas 0,1, 0-1 opcionalidad opcionalidad m..n, m-n una a muchas una a muchas una a una 4. Polimorfismo Hace referencia a la posibilidad de que dos métodos implementen distintas acciones, aun teniendo el mismo nombre, dependiendo del objeto que lo ejecuta o de los parámetros que recibe. La palabra polimorfismo proviene del griego, y significa que posee varias formas diferentes. Este es uno de los conceptos esenciales de una programación orientada a objetos. Así como la herencia está relacionada con las clases y su jerarquía, el polimorfismo se relaciona con los métodos. El polimorfismo permite referirse a objetos de clases diferentes mediante el mismo elemento. Imaginamos que disponemos de una clase profesor (Teacher) que también hereda de ser persona (Person) y que ambas disponen del método trabaja (work) y que ambos evidentemente lo hacen de una forma distinta. En general, hay tres tipos de polimorfismo: Polimorfismo de sobrecarga Polimorfismo paramétrico (también llamado polimorfismo de plantillas) Polimorfismo de inclusión (también llamado redefinición o subtipado) El polimorfismo de sobrecarga ocurre cuando las funciones del mismo nombre existen, con funcionalidad similar, en clases que son completamente independientes una de otra (éstas no tienen que ser clases secundarias de la clase objeto). Por ejemplo, la clase complex, la clase image y la clase link pueden todas tener la función "display". Esto MC Beatriz Beltrán Martínez / MC Miguel Rodríguez Hernández significa que no necesitamos preocuparnos sobre el tipo de objeto con el que estamos trabajando si todo lo que deseamos es verlo en la pantalla. Por lo tanto, el polimorfismo de sobrecarga nos permite definir operadores cuyos comportamientos varían de acuerdo a los parámetros que se les aplican. Así es posible, por ejemplo, agregar el operador + y hacer que se comporte de manera distinta cuando está haciendo referencia a una operación entre dos números enteros (suma) o bien cuando se encuentra entre dos cadenas de caracteres (concatenación). El polimorfismo paramétrico es la capacidad para definir varias funciones utilizando el mismo nombre, pero usando parámetros diferentes (nombre y/o tipo). El polimorfismo paramétrico selecciona automáticamente el método correcto a aplicar en función del tipo de datos pasados en el parámetro. Por lo tanto, podemos por ejemplo, definir varios métodos homónimos de addition() efectuando una suma de valores. El método entero addition(entero, entero) devolvería la suma de dos números enteros. real addition(real, real) devolvería la suma de dos flotantes. caracter addition(caracter, caracter) daría por resultado la suma de dos caracteres definidos por el autor. Una signature es el nombre y tipo (estático) que se da a los argumentos de una función. Por esto, una firma de método determina qué elemento se va a llamar. La habilidad para redefinir un método en clases que se hereda de una clase base se llama especialización. Por lo tanto, se puede llamar un método de objeto sin tener que conocer su tipo intrínseco: esto es polimorfismo de subtipado. Permite no tomar en cuenta detalles de las clases especializadas de una familia de objetos, enmascarándolos con una interfaz común (siendo esta la clase básica). Imagine un juego de ajedrez con los objetos rey, reina, alfil, caballo, torre y peón, cada uno heredando el objeto pieza. El método movimiento podría, usando polimorfismo de subtipado, hacer el movimiento correspondiente de acuerdo a la clase objeto que se llama. Esto permite al programa realizar el movimiento.de_pieza sin tener que verse conectado con cada tipo de pieza en particular. 5. Encapsulamiento La encapsulación es un mecanismo que consiste en organizar datos y métodos de una estructura, conciliando el modo en que el objeto se implementa, es decir, evitando el MC Beatriz Beltrán Martínez / MC Miguel Rodríguez Hernández acceso a datos por cualquier otro medio distinto a los especificados. Por lo tanto, la encapsulación garantiza la integridad de los datos que contiene un objeto. El usuario de una clase en particular no necesita saber cómo están estructurados los datos dentro de ese objeto, es decir, un usuario no necesita conocer la implementación Al evitar que el usuario modifique los atributos directamente y forzándolo a utilizar funciones definidas para modificarlos (llamadas interfaces), se garantiza la integridad de los datos (por ejemplo, uno puede asegurarse de que el tipo de datos suministrados cumple con nuestras expectativas bien que los se encuentran dentro del periodo de tiempo esperado). La encapsulación define los niveles de acceso para elementos de esa clase. Estos niveles de acceso definen los derechos de acceso para los datos, permitiéndonos el acceso a datos a través de un método de esa clase en particular, desde una clase heredada o incluso desde cualquier otra clase. Existen tres niveles de acceso: público: funciones de toda clase pueden acceder a los datos o métodos de una clase que se define con el nivel de acceso público. Este es el nivel de protección de datos más bajo protegido: el acceso a los datos está restringido a las funciones de clases heredadas, es decir, las funciones miembro de esa clase y todas las subclases privado: el acceso a los datos está restringido a los métodos de esa clase en particular. Este es nivel más alto de protección de datos Hacer las variables que son innecesarias para el tratamiento del objeto pero necesarias para su funcionamiento privadas, así como las funciones que no necesitan interacción del usuario o que solo pueden ser llamadas por otras funciones dentro del objeto (Como por ejemplo, palpitar) La encapsulación es muy conveniente y nos permite colocar en funcionamiento nuestro objeto en cualquier tipo de sistema, de una manera modular y escalable (algunas de las reglas de la ingeniería del software). La técnica del encapsulamiento consiste en reunir todos los elementos que pertenecen a una misma entidad y otorgarles un determinado nivel de aislamiento según convenga. El aislamiento protege a los datos asociados a un objeto contra su modificación por actores que no tengan derecho sobre ellos. Gracias a esto el usuario de la clase solo se ha de concentrar en el uso de la misma y no en como realmente funcionan sus métodos. Una clase representa la encapsulación de una abstracción. Esto, nos viene a decir que cada clase ha de tener dos partes, una Interfaz y una implementación. La interfaz sería una definición de los elementos de la clase y la implementación corresponde al funcionamiento de la misma. MC Beatriz Beltrán Martínez / MC Miguel Rodríguez Hernández
