• No results found

Codes that emerged from the interviews 37 

CHAPTER 4:   DATA ANALYSES AND INTERPRETATION 34

4.3  Analysing and contextualizing the interviews 37 

4.3.1  Codes that emerged from the interviews 37 

orientado

a objetos

Los lenguajes de programación siempre se han diseñado en torno a dos con- ceptos fundamentales: los datos y el código que opera sobre los datos. Los len- guajes han evolucionado a lo largo del tiempo para cambiar el modo en que estos dos conceptos interactúan. En un principio, lenguajes como Pascal y C invitaban a los programadores a escribir software que tratara al código y a los datos como dos cosas separadas, sin ninguna relación. Este enfoque dio a los programadores la libertad, pero también la obligación, de elegir el modo en que su código gestio- na los datos.

Además, este enfoque obligaba al programador a traducir el mundo real que se quería modelar usando software, a un modelo específico para ordenadores que usaba datos y código.

Los lenguajes como Pascal y C se construyeron en torno al concepto de proce-

dimiento. Un procedimiento es un bloque de código con nombre, exactamente

igual que los actuales métodos de C#. El estilo de software desarrollado usando estos lenguajes se llama programación procedural.

En la programación procedural, el programador escribe uno o más procedi- mientos y trabaja con un conjunto de variables independientes definidas en el programa. Todos los procedimientos pueden verse desde cualquier parte del códi- go de la aplicación y todas las variables pueden ser manipuladas desde cualquier parte del código.

En los años 90, la programación procedural dio paso a lenguajes como Smalltalk y Simula, que introdujeron el concepto de objeto. Los inventores de estos lengua- jes se dieron cuenta de que el ser humano no expresa ideas en términos de bloques de código que actúan sobre un grupo de variables; en su lugar, expresan ideas en términos de objetos. Los objetos son entidades que tienen un conjunto de valores definidos (el estado del objeto) y un conjunto de operaciones que pueden ejecutar- se sobre ese objeto (los comportamientos del objeto). Por ejemplo, imagine un cohete espacial.

Un cohete espacial tiene estados, como la cantidad de combustible o el número de pasajeros a bordo, y comportamientos, como "despegar" y "aterrizar". Además, los objetos pertenecen a clases. Los objetos de la misma clase tienen el mismo estado y el mismo conjunto de comportamientos. Un objeto es un caso concreto de una clase. El cohete espacial es una clase, mientras que el cohete espacial llamado Discovery es un objeto, un caso concreto de la clase cohete espacial.

NOTA: En realidad, ni siquiera en la programación procedural son visibles

todos los procedimientos ni todas las variables. Igual que en C#, los len- guajes procedurales tienen reglas de ámbito que controlan la visibilidad del código y de los datos. Por lo general podemos hacer visibles los proce- dimientos y los datos (a los que nos referiremos en este capítulo como elementos) en el procedimiento, archivo fuente, aplicación o nivel externo. El nombre de cada ámbito es autoexplicativo. Un elemento visible en el nivel de procedimiento sólo es accesible dentro del procedimiento en el que se define. No todos los lenguajes permiten crear procedimientos dentro de otros procedimientos. Un elemento visible en el nivel de archivo fuente es visible dentro del archivo en el que se define el elemento. En el nivel de aplicación, el elemento es visible desde cualquier parte de código en la misma aplicación. En el nivel externo, el elemento es visible desde cual- quier parte de código en cualquier aplicación.

El punto principal es que, en programación procedural, la interacción entre datos y código está controlada por los detalles de implementación, como el archivo fuente en el que se define una variable. Una vez que se decide hacer visible una variable fuera de sus propios procedimientos, no se obtiene ayuda para proteger el acceso a esa variable. En aplicaciones grandes con varios miles de variables, esta falta de protección suele acarrear fallos difíciles de encontrar.

El desarrollo de software orientado a objetos tiene dos claras ventajas sobre el desarrollo de software procedural. La primera ventaja es que se puede especificar lo que debe hacer el software y cómo lo hará usando un vocabulario familiar a los usuarios sin preparación técnica. El software se estructura usando objetos. Estos objetos pertenecen a clases con las que el usuario del mundo de los negocios, al

que está destinado, está familiarizado. Por ejemplo, durante el diseño de soft- ware ATM, se usan clases como C u e n t a B a n c a r i a, Cliente, Presen- tación y similares.

Esto reduce el trabajo necesario para traducir una situación del mundo real al modelo de software y facilita la comunicación con la gente ajena al software y que está interesada en el producto final. Este modo más sencillo de diseñar soft- ware ha conducido a la aparición de un estándar para describir el diseño del software orientado a objetos. Este lenguaje es el Lenguaje unificado de modelado o UML.

La segunda ventaja del software orientado a objetos se demuestra durante la implementación. El hecho de que ahora podemos tener ámbitos de nivel de clases, permite ocultar variables en las definiciones de clase. Cada objeto tendrá su pro- pio conjunto de variables y estas variables por lo general solamente serán accesi- bles mediante las operaciones definidas por la clase. Por ejemplo, las variables que contienen un estado del objeto C u e n t a B a n c a r i a sólo serán accesibles llamando a las operaciones R e t i r a d a ( ) o D e p ó s i t o ( ) asociadas a ese objeto. Un objeto CuentaBancaria (o cualquier otro objeto) no tiene acceso a otro estado privado del objeto CuentaBancaria, como el balance. A este princi- pio se le llama encapsulación.

El desarrollo de software orientado a objetos se fue haciendo más popular a medida que los programadores adoptaban este nuevo modo de diseñar software. C# es un lenguaje orientado a objetos y su diseño garantiza que los programado- res de C# sigan los conceptos correctos de la programación orientada a objetos.

NOTA: SmallTalk, Java y C# son lenguajes orientados a objetos puros

porque no se puede escribir un programa sin usar objetos. A otros lengua- jes, como C y Pascal, se les llama lenguajes procedurales o no orientados a objetos porque no disponen de compatibilidad integrada que permita crear objetos. Existe un tercer tipo de lenguajes híbridos, como C++, en los que se puede elegir si usar o no objetos. Bjarne Stroustrup, el inventor de C++, decidió no obligar a los programadores de C++ a usar objetos porque C++ también era una versión mejorada del lenguaje de programación C. La com- patibilidad con el código C existente ayudaba a que C++ se convirtiera en un lenguaje importante.

En este capítulo se estudian los conceptos que componen un lenguaje orientado a objetos, empezando por sus componentes esenciales (las clases y objetos), hasta los términos más avanzados (abstracción, tipos de datos abstractos, encapsulación, herencia y polimorfismo).

Se tratarán los conceptos básicos y se procurará evitar los detalles específicos sobre cómo están implementados estos conceptos en C#. Estos detalles específi- cos se tratarán en capítulos posteriores.