Edger w. Dijkstra.

Programadores y Arte

La programación estructurada tuvo su mayor auge en la década de los setenta. Entonces se dictaron m{múltiples conferencias para entender sus conceptos, se vendieron muchos sistemas diseñados bajo un enfoque modular. Han pasado muchos años desde su nacimiento, y a pesar de las desventajas de este tipo de programas, este tipo de programación, una gran cantidad de programadores (inclusive programadores) aún no comprenden la modularidad o las estructuras de control.

 

Esto proviene del perfil con el cual se forma a los programadores. Se ha repetido en muchos libros que programar es un arte, esto convierte por ende, al programador en artista. Se nos ha educado para pensar que un programa es toda una obra de arte nacida de la inspiración de los genios del teclado y el monitor, razón por el cual cada programador ve a su obra como algo irrepetible en la historia de la humanidad y que, por tanto, esta totalmente libre de un juicio de valor. Al ser los programas elevados al nivel de obras de arte, nadie puede emitir juicios axiológicos válidos sobre la excelencia de dicha obra.

 

Lo abstracto del termino programa y la concepción artística totalmente subjetiva que hace el programador de su obra, limitan el criterio para aplicar una metodologia a la creación de software.

 

¿Deben dos analistas de sistemas desarrollar una lista idéntica de requerimientos cuando estudian en forma simultánea e independiente la misma situación? En forma intuitiva así debería ser. ¿Por que entonces dos programadores no deberían de usar las mismas estructuras para implantar el mismo algoritmo?

 

Es válido y toltamente humano adjudicar a la creatividad de cada persona un papel predominante durante la implantación de programas. Pero para lograr hacer de las programación una ciencia, es preciso que los profesionales sigan una disciplina de diseño e implantación. Ya no es posible seguir pensando en que la programación es un arte. Los métodos de inteligencia artificial (AI), diseño asistido por computadora (CAD), sistemas expertos, etc; exigen más que arte. Los alquimistas no sobrevivieron a los químicos. Los artistas en programación no sobreviviran a los ingenieros en software. La sociedad requiere de personas preparadas y, estando en los albores del siglo XXI, no es posible que el metodo científico no llegue a un área que desde su nacimiento de ha considerado "cosa de sabios".

 

Programación Orientada a Objetos

 

La programación orientada a objeto, OOP (Object Oriented Programming) a partir de ahora, se trata de una evolución de la programación procedural basada en funciones, que permite agrupar elementos de código (rutinas y datos) con funcionalidades similares, bajo un sistema unificado de manipulación y acceso a dichos elementos.

 

La organización de una aplicación en OOP se realiza mediante estructuras de código.
Una estructura de código contiene un conjunto de procedimientos e información que ejecutan una serie de procesos destinados a resolver un grupo de tareas con un denominador común. Una aplicación orientada a objetos tendrá tantas estructuras de código como aspectos del programa sea necesario resolver.

 

Un procedimiento que esté situado dentro de una de estructura de este tipo, no podrá llamar ni ser llamado por otro procedimiento situado en una estructura distinta, si no es bajo una serie de reglas. Lo mismo sucederá con los datos que contenga la estructura, permanecerán aislados del exterior, y sólo serán accesibles siguiendo ciertas normas. Una estructura de código, es lo que en OOP identificamos como objeto.

 

Al ser las estructuras de código u objetos, entidades que contienen una información precisa y un comportamiento bien definido a través del conjunto de procedimientos que incluyen, pueden ser clasificados en función de las tareas que desempeñan. Precisamente, uno de los fines perseguidos por la OOP es conseguir una mejor catalogación del código, en base a estructuras jerárquicas dependientes, al estilo de un árbol genealógico.

 

Trasladando las nociones que acabamos de exponer al ejemplo anterior, en el cual se programaban los procesos de gestión de los empleados de una empresa, el resultado obtenido será una estructura de código conteniendo todos los procedimientos, funciones y variables de la aplicación, implicados en las operaciones a realizar con un empleado, o lo que es lo mismo, un objeto Empleado. Entre los elementos de este objeto encontraremos el nombre, apellidos, alta del empleado, pago de nómina, etc.

 

Todos los elementos que forman parte de un objeto componen la clase del objeto. Una clase consiste en el conjunto de especificaciones que permiten crear los objetos; en el caso expuesto por el ejemplo anterior sería la clase Empleado.

 

Como acabamos de comprobar, las motivaciones que han llevado al desarrollo de la OOP son facilitar una mejor organización y clasificación del código, que la proporcionada por la programación procedural tradicional; aproximando al mismo tiempo, el modo de programar a la manera en que nuestra mente trabaja para aplicar soluciones a los problemas planteados.

 

Objetos
Un objeto es una agrupación de código, compuesta de propiedades y métodos, que pueden ser manipulados como una entidad independiente. Las propiedades definen los datos o información del objeto, permitiendo consultar o modificar su estado; mientras que los métodos son las rutinas que definen su comportamiento.

 

Un objeto es una pieza que se ocupa de desempeñar un trabajo concreto dentro de una estructura organizativa de nivel superior, formada por múltiples objetos, cada uno de los cuales ejerce la tarea particular para la que ha sido diseñado.

 

Clases
Una clase no es otra cosa que el conjunto de especificaciones o normas que definen cómo va a ser creado un objeto de un tipo determinado; algo parecido a un manual de instrucciones conteniendo las indicaciones para crear el objeto.

 

Los términos objeto y clase son utilizados en OOP con gran profusión y en contextos muy similares, por lo que para intentar aclarar en lo posible ambos conceptos, diremos que una clase constituye la representación abstracta de algo, mientras que un objeto constituye la representación concreta de lo que una clase define.

 

La clase determina el conjunto de puntos clave que ha de cumplir un objeto para ser considerado perteneciente a dicha clase o categoría, ya que no es obligatorio que dos objetos creados a partir de la misma clase sean exactamente iguales, basta con que cumplan las especificaciones clave de la clase.

 

Expongamos ahora las anteriores definiciones mediante un ejemplo preciso: un molde para crear figuras de cerámica y las figuras obtenidas a partir del molde. En este caso, el molde representaría la clase Figura, y cada una de las figuras creadas a partir del molde, sería un objeto Figura. Cada objeto Figura tendrá una serie de propiedades comunes: tamaño y peso iguales; y otras propiedades particulares: un color distinto para cada figura.

 

Aunque objetos distintos de una misma clase pueden tener ciertas propiedades diferentes, deben tener el mismo comportamiento o métodos. Para explicar mejor esta circunstancia, tomemos el ejemplo de la clase Coche; podemos crear dos coches con diferentes características (color, tamaño, potencia, etc.), pero cuando aplicamos sobre ellos los métodos Arrancar, Acelerar o Frenar, ambos se comportan o responden de la misma manera.

 

Abstracción
La abstracción es aquella característica que nos permite identificar un objeto a través de sus aspectos conceptuales. Las propiedades de los objetos de una misma clase, pueden hacerlos tan distintos que sea difícil reconocer que pertenecen a una clase idéntica. No obstante, nosotros reconocemos a qué clase pertenecen, identificando además, si se trata de la misma clase para ambos. Ello es posible gracias a la abstracción.

 

Tomemos como ejemplo dos objetos coche, uno deportivo y otro familiar; su aspecto exterior es muy diferente, sin embargo, cuando pensamos en cualquiera de ellos, sabemos que ambos pertenecen a la clase Coche, porque realizamos una abstracción o identificación mental de los elementos comunes que ambos tienen (ruedas, volante, motor, puertas, etc.).

 

Del mismo modo que hacemos al identificar objetos reales, la abstracción nos ayuda a la hora de desarrollar una aplicación, permitiéndonos identificar los objetos que van a formar parte de nuestro programa, sin necesidad de disponer aún de su implementación; nos basta con reconocer los aspectos conceptuales que cada objeto debe resolver.

 

Por ejemplo, cuando abordamos el desarrollo de un programa de gestión orientado a objetos, realizamos una abstracción de los objetos que necesitaríamos para resolver los procesos del programa: un objeto Empleado, para gestionar al personal de la empresa; un objeto Factura, para gestionar las ventas realizadas de productos; un objeto Usuario, para verificar las personas que utilizan la aplicación, etc.

 

Encapsulación
La encapsulación establece la separación entre el interfaz del objeto y su implementación,
aportándonos dos ventajas fundamentales. Por una parte proporciona seguridad al código de la clase, evitando accesos y modificaciones no deseadas; una clase bien encapsulada no debe permitir la modificación directa de una variable, ni ejecutar métodos que sean de uso interno para la clase.

 

Por otro lado la encapsulación simplifica la utilización de los objetos, ya que un programador que use un objeto, si este está bien diseñado y su código correctamente escrito, no necesitará conocer los detalles de su implementación, se limitará a utilizarlo.
Tomando un ejemplo real, cuando nosotros utilizamos un objeto Coche, al presionar el acelerador, no necesitamos conocer la mecánica interna que hace moverse al coche, sabemos que el método Acelerar del coche es lo que tenemos que utilizar para desplazarnos, y simplemente lo usamos.

 

Pasando a un ejemplo en programación, si estamos creando un programa de gestión y nos
proporcionan un objeto Cliente que tiene el método Alta, y sirve para añadir nuevos clientes a la base de datos, no precisamos conocer el código que contiene dicho método, simplemente lo ejecutamos y damos de alta a los clientes en nuestra aplicación.

 

Polimorfismo
El polimorfismo determina que el mismo nombre de método, realizará diferentes acciones según el objeto sobre el que sea aplicado. Al igual que sucedía en la encapsulación, el programador que haga uso del objeto, no necesita conocer los detalles de implementación de los métodos, se limita a utilizarlos.

 

Pasando a un ejemplo real, tomamos dos objetos: Pelota y VasoCristal; si ejecutamos sobre ambos el método Tirar, el resultado en ambos casos será muy diferente; mientras que el objeto Pelota rebotará al llegar al suelo, el objeto VasoCristal se romperá.
En un ejemplo aplicado a la programación, supongamos que disponemos de los objetos Ventana y Fichero; si ejecutamos sobre ambos el método Abrir, el resultado en Ventana será la visualización de una ventana en el monitor del usuario; mientras que en el objeto Fichero, se tomará un fichero en el equipo del usuario y se dejará listo para realizar sobre él operaciones de lectura o escritura.

 

Herencia
Se trata de la característica más importante de la OOP, y establece que partiendo de una clase a la que denominamos clase base, padre o superclase, creamos una nueva clase denominada clase derivada, hija, o subclase. En esta clase derivada dispondremos de todo el código de la clase base, más el nuevo código propio de la clase hija, que escribamos para extender sus funcionalidades.

 

A su vez podemos tomar una clase derivada, creando una nueva subclase a partir de ella, y así sucesivamente, componiendo lo que se denomina una jerarquía de clases, que explicaremos seguidamente.

 

Existen dos tipos de herencia: simple y múltiple. La herencia simple es aquella en la que creamos una clase derivada a partir de una sola clase base, mientras que la herencia múltiple nos permite crear una clase derivada a partir de varias clases base. El entorno de .NET Framework sólo permite utilizar herencia simple.

 

Como ejemplo real de herencia, podemos usar la clase Coche como clase base; en ella reconocemos una serie de propiedades como Motor, Ruedas, Volante, etc., y unos métodos como Arrancar, Acelerar, Frenar, etc. Como clase derivada creamos CocheDeportivo, en la cuál, además de todas las características mencionadas para la clase Coche, encontramos propiedades y comportamiento específicos como ABS, Turbo, etc.

Un ejemplo basado en programación consistiría en disponer de la ya conocida clase Empleado. Esta clase se ocupa, como ya sabemos, de las operaciones de alta de empleados, pago de nóminas, etc.; pero en un momento dado, surge la necesidad de realizar pagos a empleados que no trabajan en la central de la empresa, ya que se trata de comerciales que pasan la mayor parte del tiempo desplazándose. Para realizar dichos pagos usaremos Internet, necesitando el número de tarjeta de crédito y la dirección email del empleado. Resolveremos esta situación creando la clase derivada CiberEmpleado, que hereda de la clase Empleado, en la que sólo tendríamos que añadir las nuevas propiedades y métodos para las transacciones electrónicas, puesto que las operaciones tradicionales ya las tendríamos disponibles por el mero hecho de haber heredado de Empleado.