Programación orientada a objetos (POO) Si algo produce temor, al coger cualquier interfaz de desarrollo moderna, es saber que su programación está orientada a objetos. El término en sí ya da miedo. Qué es eso de objetos y qué es lo que debemos variar respecto a nuestra programación estructurada tradicional, y además por qué hemos de hacerlo. Vamos a intentar desvelar los misterios se esconde y a convencernos de su validez y utilidad y, sobre todo, que no es tan complejo como parece indicarnos la teoría. La POO surge como una evolución natural de la programación estructurada acto seguido no es algo que rompa esquemas clásicos como podría suponerse. La POO formaliza técnicas utilizadas en dicha programación estructurada. Esta es la mejor manera de comprender en un primer momento su misión. Ahora bien, su definición es algo más obtusa y filosófica, ya que académicamente podemos decir que la POO aplica los objetos del mundo real a nuestras aplicaciones. De ahí el concepto de orientación a objetos. Un objeto es algo tangible que tiene unas características y un comportamiento. En el mundo real podemos hablar de objetos silla, automáticamente construimos en nuestro cerebro un determinado tipo de silla, pero en cualquiera de los casos lo hacemos siempre con las características con las que nuestra percepción reconoce el objeto silla. Tendrá un respaldo, un asiento, un soporte, un color, etc. Este concepto de silla es lo que llamamos clase. Una clase es la abstracción de un objeto, es algo intangible, es el conjunto de ideas, no es algo real. A la acción de crear un objeto partiendo de una clase se llama instanciamiento. Ya tenemos dos conceptos que en la POO van a ser fundamentales, las clases y los objetos. Nosotros pasaremos gran parte del tiempo dedicándolo a diseñar clases, a crear abstracciones que sean inherentes a muchos objetos, o mi- rándolo desde el punto de vista informático, al código que utilicemos repetidamente en muchos módulos. He aquí una de las claves de la POO reutilizar el código. Muchas veces hablaremos de clases y de objetos indistintamente, no hay que confundirlos, pero tampoco hay que considerarlos como algo distinto. Nosotros podemos manipular las clases y los objetos, mientras que el usuario sólo puede actuar sobre los objetos. En nuestras aplicaciones, por tanto, siempre debemos convertir, es decir instanciar las clases en objetos. Volviendo al ejemplo de la silla, si a la abstracción, esto es, a la clase silla, le damos unas características específicas como pueden ser: tapicería de cuero, color negro, soporte giratorio y con ruedas, respaldo doble de alto, tendríamos en la mente el nombre silla de ejecutivo. Es realmente un objeto, pero un objeto que tiene unas características tan definidas y que se repite en muchos objetos silla, que podemos considerar a este tipo como una clase de silla. Ahora bien, al partir del concepto genérico de silla estaremos hablando de una subclase. Por tanto, de una clase genérica o mejor llamada clase base, podemos crear subclases y éstas a su vez tener más subclases, así formaremos una jerarquía de clases. Propiedades, Eventos Y Métodos. Hasta ahora hemos hablado de características de los objetos. Bien, en la terminología de la POO, a éstas se les llama propiedades. Por tanto, todos los objetos tienen unas propiedades que los distinguen de otros. Del mismo modo, el mundo real es algo dinámico y, por lo tanto, las cosas, esto es, los objetos, están expuestos a acciones externas y, a pesar de ser inanimados, pueden cambiar su estado dependiendo de esas acciones. Por ejemplo, si nos acostamos sobre Cotecnor • Programación I • Programación Orientada o Objetos 1 respaldo flexible de una silla, éste se echará hacia atrás. Se ha producido una acción, recostarse, y una reacción, echarse hacia atrás el respaldo. En la POO, a las acciones les llamaremos eventos y a las reacciones métodos. Si esto lo aplicamos a la programación, los eventos serán acciones del usuario sobre nuestra aplicación y los métodos eran código asociado a cada evento. Ahora bien, también pueden existir métodos que no respondan a eventos, aunque esto no es del todo preciso, ya que, si responden a una acción, que es la que nosotros realizamos programáticamente a llamar a dicho método. Bien, entonces ya tenemos los elementos con los que vamos a jugar en la POO: las clases, los objetos, las propiedades, los eventos y los métodos. Esto es lo que debemos saber y dominar, ni más ni menos. Clasificación de métodos Los métodos se pueden ratificar en cuatro tipos que son los siguientes: Constructores. Un constructor es el primer método que se ejecuta al realizar la instancia del objeto. Uno de los usos principales de un constructor es la inicialización de los atributos de la clase. Debe tener visibilidad pública y no posee retorno. Consultores. Un consultor es el método que permite retornar al valor de un atributo con visibilidad privada al aplicar el concepto de encapsulamiento. Modificadores. Un modificador es el método que permite asignar valor a un atributo con visibilidad privada al aplicar el concepto de encapsulamiento. Analizadores. Un analizador es el método que permite implementar la lógica del servicio del mismo, es decir, allí se implementan los algoritmos requeridos. Visibilidad La visibilidad se refiere al nivel de accesibilidad de los atributos y métodos. Los niveles de accesibilidad se dan por los siguientes términos: Privado: se puede acceder desde un método implementado desde la misma clase. Público: se puede acceder desde un método implementado en cualquier clase. Protegido: se puede acceder desde un método implementado en una clase que herede la clase que contiene esta visibilidad y desde clases implementadas en el mismo paquete. Objetos del mundo que nos rodea y del mundo informático. Llegado este punto, es fácil que como estudiante encuentre todo esto como un desvarío que poco o nada tiene que ver con la programación y sí mucho con filosofía barata. Pero hagamos ahora una traslación de lo dicho a nuestro mundo. Parece que nos tenemos que dedicar a convertir nuestros programas en poco menos que una colección objetos tales como mesas, coches, árboles, etc. Realmente la POO sí que dice que esto sea así, un ejemplo menos estereotipado sería el objeto artículo, o el objeto cliente, ambos son entidades que tienen unas propiedades y se realizan acciones con ellos. Ahora bien, tan cierto es que estos objetos, como que también nuestro mundo, el informático, tiene objetos. ¿O no lo son, las ventanas, los botones, la lista desplegables…? Todos ellos son elementos que también tienen unas características propias y actúan de diversa forma respecto a los eventos realizados por nuestro opuesto, que no es otro que el usuario final. Por tanto, tal vez sea más fácil, Cotecnor • Programación I • Programación Orientada o Objetos 2 asimilar la POO pensando de objetos de nuestro entorno de programación, de la interfaz, etc. que en algo tan vasto como el entorno vital. Nuestra mente cuadrícula lo agradecerá. Características de la POO Los componentes están vistos, pero que más nos ofrece la POO para que sea útil. Bien, veamos tres fundamentales. mos de todas las posibilidades. Por último, podemos impedir que una propiedad o método heredado pueda ser modificado en algún sitio que no sea la clase de base, esto es lo que se denomina proteger la propiedad o método. Polimorfismo También es una característica propia de la POO y consiste en que varios objetos, aunque partan de distintas clases, tengan métodos o propiedades con el mismo nombre y que actúen de distinta forma. Tiene una relación directa con la herencia, ya que un método o propiedad heredado se puede sobre escribir y por tanto puede actuar de distinta forma o de lo que hacía en la clase base. Herencia Una de las principales ventajas de la POO. La herencia se hace a crear subclases u objetos. Consiste en que éstos tienen las propiedades y métodos que hayamos definido en la clase base, por lo que no tendremos que repetirlos. Aquí aparece una de las razones, la reutilización del código. Nosotros, en la programación estructurada, utilizamos el famoso método de copiar y pegar todo lo que nos sirve de otro programa que tuviéramos hecho. Encapsulación En la POO, hay que poner ese código que nos vale en una clase y, sólo con esto, todas las subclases y objetos que creemos partiendo de esa clase tendrán, sin hacer nada, es el código sin tener por tanto que reescribirlo. Además, cuántas veces hemos tenido que retocar un código por un pequeño error de sintaxis cuando ya la habíamos “pegado” en varios módulos y, por tanto, deberemos modificar en cada uno de ellos. O ese color de ventana que no le gusta el usuario y que hemos empleado en las cuarenta y siete que tiene aplicación, por lo que ahora tenemos que modificarlas una a una. Gracias a la POO ya no tendremos que hacerlo, puesto que la herencia funciona automáticamente, por lo que iremos a la clase base y modificaremos esa propiedad o ese método que estaba mal y voilá, el cambio se reflejará en todas las clases y objetos que se crearon a partir de dicha clase. Sólo por esto, merece la pena programar con orientación a objetos. Claro, que muchas veces va suceder que una determinada propiedad o método no nos sirve. Esto tampoco representa un problema, ya que no estamos obligados a tener que heredarlo, sino que podemos sobreescribir el método o la propiedad en cuestión. Directamente sucederá cuando escribamos en la propiedad o en el método. También podemos utilizar el código heredado y sumarle el propio que nos interese. En fin, dispone- Siguiendo con la dinámica de actuación de la POO, al crear clases lo que estamos haciendo implícitamente es agrupar propiedades y métodos para qué, cuando tengamos que hacer otra aplicación, cojamos esa clase y la pongamos en ellas sin tener que cambiar nada. A esto se le llama encapsulación. En la programación estructurada teníamos código dispersado en módulos, programas, etc., y en la POO todo lo guardamos en el mismo sitio, en la clase u objeto, lo encapsulamos. Si queremos utilizar una propiedad o método debemos llamar al objeto en cuestión mediante mensajes. Los podríamos asociar con las clásicas llamadas a funciones o procedimientos almacenados. La encapsulación, por tanto, ayuda también a la reutilización del código y de hacer más fácil su búsqueda en nuestras aplicaciones. Clases visuales y no visuales Como hemos entrado de lleno en las clases de podemos llamar informáticas, está muy clara la división que se puede hacer. Por un lado, tenemos aquellas clases que se va a convertir en objetos en pantalla y que, por tanto, tienen representación gráfica, son las clases visuales; por otro lado, la que son una colección de propiedades y métodos que no son llamados desde otros objetos pero que no forman parte de la interfaz, son las clases no Cotecnor • Programación I • Programación Orientada o Objetos 3 visuales. • Clases contenedoras • • • De todas estas clases se puede hacer otro tipo de división que viene marcada por aquellas que pueden tener dentro del sí a otras clases. Los objetos contenidos se denomina objetos miembros y automáticamente pasan a depender de su contenedor. Como veremos, se complica bastante el código de nuestros programas, pero va a ser inevitable trabajar con este tipo de clases. Su utilización encapsula aún más el código, ya que permite agrupar objetos. Controles Por último, también se pueden agrupar las clases teniendo en cuenta si debe incluirse obligatoriamente dentro de un formulario para que puedan visualizarse en pantalla. Son objetos dependientes del formulario. Pros y contras de la POO Después de visto todo lo referente a orientación objetos se pueden sacar conclusiones, que deben ser positivas en su mayor parte. La POO nos facilita: • Reutilizar el código • • • • • Modificar, de una sola vez, varias partes de una aplicación Ordenar y agrupar código según su finalidad Analizar con mayor vigor nuestras aplicaciones Adaptar nuestro código a otras aplicaciones, aunque no sean nuestras Encontrar errores más rápidamente Agregar las capacidades y prestaciones Interactuar con el usuario y controlar mejor sus acciones Eliminar redundancias de código Documentar más cómodamente las aplicaciones Sin embargo, no todos son ventajas y nos encontramos con algunos aspectos que no pueden llegar a modificar bastante nuestros hábitos de programación. Así tenemos problemas como: • La herencia no reescribe el código en pantalla, por lo que continuamente debemos ir a las clases padre y a veces no sabemos si algún error está en objeto o en la clase. • La fase de análisis se alarga considerablemente, ya que no podemos sentarnos delante del computador y ponernos a teclear código. • Debemos organizarnos con suma precisión. De lo contrario puede redundar se código en clases distintas o crearse clases distintas para el mismo fin. • Muchas veces se deben incluir más código del necesario en una aplicación, ya que es inseparable de la clase. • Crear muchas subclases puede ralentizar nuestras aplicaciones, por lo que conviene no abusar. Haciendo un balance general y comparándolo con la programación estructurada, podemos decir que seguimos haciendo lo mismo, pero con unas directrices bien definidas. Ahora bien, el que piense que va a obtener resultados, en cuanto a productividad, pocos días, está realmente equivocado. La POO comienza a ser rentable cuando se ha realizado unas cuantas aplicaciones y tenemos verdaderamente código para reutilizar. El número de clases que puede llegar a tener una empresa de desarrollo puede ser inmenso, pero las aplicaciones que se respiran se realizarán en menos tiempo y con más fiabilidad; en definitiva, lo que todos deseamos. Cotecnor • Programación I • Programación Orientada o Objetos 4
