Introducción a la Programación Orientada a Objetos
1
Introducción
Ya que la OOP no es un lenguaje de programación, puede aplicarse a cualquier lenguaje, y de hecho hoy en día está disponible en mayor o menor medida en todos los lenguajes tradicionales (C se ha convertido en C++, Pascal en Delphi, VB incorpora parte de la OOP) y no aparece un lenguaje nuevo sin que incluya OOP (como es el caso de Java). Es por esto que intentaremos que todo lo que aquí se diga pueda ser aplicado a cualquier lenguaje OOP.Sin embargo, cuando llegue el momento de escribir código, emplearemos una sintaxis híbrida de C++ y Java que según la opinión del autor del curso es la que puede resultar más clara independientemente del lenguaje al que se acaben aplicado estos conocimientos.Para empezar, rogaríamos al lector experimentado en programación, que dejase a un lado todas sus ideas preconcebidas acerca de cómo debe realizarse un programa, la OOP tiene muy poco que ver con su forma habitual de trabajo, e incluso de ver el mundo; de hecho, los no programadores, captan mucho antes estas ideas, ya que no tienen prejuicios ni lastres ideológicos que les frenen.Tenga en cuenta que usted, programador o no, ya sabe qué es un objeto y cómo manipularlo, lo lleva haciendo desde que nació; si entiende la similitud entre los objetos del mundo físico y los informáticos, la OOP le parecerá cosa de niños, pero no nos llevemos a engaño, éste es el punto más
3
Programación Orientada al Objeto
Definición de Objeto
No se asuste, nuestra definición de objeto, como podrá comprobar es mucho más fácil. En OOP, un objeto es un conjunto de datos y métodos; como imaginamos que se habrá quedado igual, le vamos a dar más pistas.Los datos son lo que antes hemos llamado características o atributos, los métodos son los comportamientos que pueden realizar.Lo importante de un sistema OOP es que ambos, datos y métodos están tan intrínsecamente ligados, que forman una misma unidad conceptual y operacional. En OOP, no se pueden desligar los datos de los métodos de un objeto. Así es como ocurre en el mundo real.Vamos ahora a dar una serie de ejemplos en los que nos iremos acercando paulatinamente a los objetos informáticos. Los últimos ejemplos son para aquellos que ya conocen Java y/o C; sin embargo, estos ejemplos que exigen conocimientos informáticos, no son imprescindibles para entender plenamente el concepto de clase y el de objeto.
Definición de Clase
Una clase, es simplemente una abstracción que hacemos de nuestra experiencia sensible. El ser humano tiende a agrupar seres o cosas -objetos- con características similares en grupos -clases-. Así, aun cuando existen por ejemplo multitud de vasos diferentes, podemos reconocer un vaso en cuanto lo vemos, incluso aun cuando ese modelo concreto de vaso no lo hayamos visto nunca. El concepto de vaso es una abstracción de nuestra experiencia sensible.
Conceptos básicos
Estudiaremos los conceptos de Clase, Objeto, Herencia, Encapsulación y Polimorfismo. Estas son las ideas más básicas que todo aquel que trabaja en OOP debe comprender y manejar constantemente; es por lo tanto de suma importancia que los entienda claramente. De todos modos, no se preocupe si al finalizar el presente capítulo, no tiene una idea clara de todos o algunos de ellos: con el tiempo los irá asentando y se ira familiarizando con ellos, especialmente cuando comience a trabajar creando sus propias clases y jerarquías de clases.
Lo que pretendemos con este capítulo es que usted entienda los conceptos que aquí se le van a exponer, no importa que no entienda cómo llevarlos a la práctica, o dicho de un modo más técnico, cómo implementarlos en un lenguaje concreto (C, Java, Visual Basic, FoxPro, etc.). De esto ya nos encargaremos más adelante.El concepto de Sistema de Programación Orientado al Objeto -Object Oriented Programming System (OOPS)-, y que nosotros llamamos OOP, agrupa un conjunto de técnicas que nos permiten desarrollar y mantener mucho más fácilmente programas de una gran complejidad.Veamos ahora cuales son los conceptos relacionados con la OOP.
4
Planteamiento de la implementación
Los métodos no son funciones:
No defina métodos como si fueran funciones, sino como acciones inherentes al objeto: así podrá cambiar el funcionamiento interno completamente sin que cambie ni el nombre de la clase ni los nombres de los métodos. Si al cambiar el funcionamiento de una clase el nombre de la clase y de los métodos no tienen sentido es que estaba mal diseñado.
No piense de forma procedural:
En OOP no se puede pensar de una forma procedural, una clase no es un conjunto de funciones relacionadas, es un objeto tan real como los demás que están fuera del ordenador. Los objetos son de verdad, no son cajas de almacenamiento de código.
Divide y vencerás:
Procure construir un método para realizar cada pequeña tarea que necesite. Cuanto menor sea el ámbito de actuación de un método, más probablemente le resultará reutilizable en otro momento y más fácil le resultará codificarlo. Haga lo mismo con las clases: no escatime en su número. Ante la duda, siempre es mejor dividir una clase en dos que agrupar dos en una.
Para que se haga una idea de la importancia que tiene éste diseño, le haremos saber que en los equipos de programadores que trabajan en OOP suele haber varias personas que se dedican exclusivamente al diseño de esta estructura de clases, los datos que cada una de ellas contendrá, los métodos que trabajarán con esos datos y las inter-relaciones de unas clases con otras. Estas personas, suelen ayudarse de herramientas especializadas en facilitar el desarrollo de jerarquías de clases, la más conocida es "Rational Rose". Pero incluso con la ayuda de herramientas de este tipo, la definición de las clases y sus relaciones sigue siendo más un arte que una ciencia. Y en cualquier caso, nunca el modelo diseñado sobre el papel o la herramienta es el modelo finalmente implementado; de hecho, lo más común es definir un modelo inicial e ir re-haciéndolo una y otra vez según se va implementando.
2
Programación estructurada
Lo importante aquí, es que cuando escribimos un programa usando las técnicas de programación estructurada, los saltos están altamente desaconsejados, por no decir prohibidos; en cambio en BASIC, por ejemplo, son muy frecuentes (todos conocemos el prolífico GOTO ), lo que no es nada conveniente si queremos entender algo que escribimos hace tres meses de forma rápida y clara.De hecho, cuando el traductor (ya sea intérprete o compilador) cambia nuestro programa a código máquina, lo convierte a estilo lineal, pero eso es asunto de la máquina, nosotros escribimos y corregimos nuestro programa de un modo claro, y podemos seguir el flujo de la información con facilidad.
Programación lineal
Cada línea de programa debe ir precedida de un identificador (una etiqueta) para poder referenciarla, para este ejemplo hemos utilizado números, aunque podría utilizarse cualquier otro identificador
Evolución en cuanto a la conceptualización
El primer avance en metodología de programación, vino con la Programación Estructurada (en este concepto vamos a incluir el propio y el de técnicas de Programación con Funciones -también llamado procedural-, ya que ambos se hallan íntimamente relacionados, no creemos, que se pueda concebir la programación estructurada sin el uso masivo de funciones).La programación en ensamblador es lineal, es decir, las instrucciones se ejecutan en el mismo orden en que las escribimos. Podemos, sin embargo, alterar este orden haciendo saltos desde una instrucción a otro lugar del programa distinto a la instrucción que le sigue a la que se estaba procesando.
Evolución en cuanto a la tecnología
A estas alturas, es posible que usted esté pensado que todo esto es demasiado bonito para ser cierto y que en algún lugar debe estar el problema. Efectivamente, no nos llevemos a engaño, todo esto al final, se queda en papel mojado y buenas intenciones, debe ser que al dios de la computación le agrada hacernos la vida complicada.La cuestión tiene dos vertientes bien distintas: por un lado, los programas realizados con lenguajes de alto nivel, realizan los mismo procesos de un modo más lento que de haberlos escrito con uno de bajo nivel, este problema no es demasiado gravoso si echamos un vistazo a la evolución en la potencia de cálculo de las máquinas en los últimos diez años. Salvo para programas muy específicos, o de gran rendimiento, no habría ningún problema, en escribir nuestras aplicaciones en un lenguaje de alto o bajo nivel.
El proceso de desarrollo de una aplicación con un lenguaje de alto nivel es mucho más rápido, simple y, por tanto, resulta más fácil detectar y corregir errores. Esto se debe principalmente a dos factores: por un lado, cada instrucción que escribimos en lenguaje de alto nivel puede equivaler a varias decenas e incluso cientos de instrucciones en ensamblador; por otra parte, la sintaxis de las instrucciones y los nemónicos que usamos se parecen algo más al lenguaje cotidiano (sobre todo si fuésemos angloparlantes).
Como usted probablemente sabrá, un ordenador no es más que un conjunto de microinterruptores, estos pueden estar apagados o encendidos (por lo que les llamamos elementos biestado). En un principio estos interruptores eran relés, que no es más que un electroimán que puede cerrar o abrir un circuito eléctrico. Si están apagados (no dejan pasar corriente), decimos que su estado es cero y en caso contrario uno.Un programa de ordenador no es más que una sucesión de instrucciones que se ejecutarán secuencialmente, es decir, una detrás de otra. Por tanto, como la forma de programarlos es introduciendo secuencias de ceros y unos (lo que llamamos bits); puede imaginarse la gran probabilidad que existe de error al introducir sucesiones enormemente largas; además, una vez cometido un error, intentar encontrarlo y corregirlo puede llevarnos antes al manicomio con un grave cuadro de psicosis, que a la solución del problema.
Evolución de los lenguajes de programación
Toda la historia de los lenguajes de programación se ha desarrollado en base a una sola idea conductora: hacer que la tarea de realizar programas para ordenadores sea cada vez lo más simple, flexible y portable posible.
