PDF de programación - Curso de C# - Más conceptos sobre clases

Más conceptos sobre clases: Accesibilidad de las clases, clases abstractas, herencia, constructores.... También veremos el
uso de static para acceder a un miembro de clase.

Curso de C#

Dentro de nuestra mini-sección de utilidades, nos construiremos un pequeño programa para bajar páginas web.
Completaremos con dos ejemplos para leer y escribir ficheros de texto.

Otra vez con vosotr@s en esta quinta entrega del Curso de C#. Como ya habéis leído, seguimos con las clases (y lo que nos
queda!!). En esta ocasión vamos a aprender conceptos nuevos e interesantes a la hora de diseñar nuestras propias clases, y que son
tan importantes que muchas veces no podremos pasar sin ellos. Por ejemplo: Ya vimos el control de acceso dentro de una clase,
esta vez veremos el control de acceso a la clase en sí. La herencia: algo básico en la Programación Orientada a Objetos (POO) y
que nos va a permitir muchas, muchas cosas, y todas beneficiosas. En definitiva, vamos a empezar que me enrollo y no paro.

El mes pasado vimos los modificadores que nos permitían implementar el acceso a los miembros de una clase. Bien pues ahora
veamos los....

Modificadores de clases..
Los modificadores de clase de que disponemos son: public, protected, internal, private, abstract y sealed. Los cuatro primeros
controlan la accesibilidad de la clase (el significado ya lo vimos con los métodos y ahora lo aplicamos a las clases). Algunos de
estos modificadores de acceso no estarán permitidos dependiendo del contexto en el que nos encontremos (*). El modificador
abstract nos permite definir una clase abstracta. Se usa para indicar que la clase que estamos definiendo está incompleta. Sí,
habéis leído bien: incompleta. Este tipo de clases sólo se pueden usar como clase base de otras (luego veremos qué significa esto).
Concretamente, las clases abstractas se diferencian de las "no abstractas" en que:
- Una clase abstracta no puede ser instanciada directamente. No podemos usar el operador new para crear un objeto de dicha
clase. Si lo intentamos, obtendremos un error de compilación.
- Una clase abstracta puede contener miembros abstractos, aunque no es necesario.
- Una clase abstracta no puede ser sealed. Aunque luego vamos a ver el modificador sealed, recordaréis que ya lo nombramos en
un artículo anterior. Significa "no heredable". Claro, si una clase abstracta pudiera ser sealed, chocaría frontalmente con la
afirmación hecha unas lineas más arriba acerca de que sólo podemos usar clases abstractas como clase base (es decir, clase
heredable). Es muy importante saber que los miembros abstractos de una clase abstracta deben ser sobreescritos y definidos por
completo en la clase que la herede si se quiere que ésta última clase no sea también abstracta. Tranquilos, enseguida vemos un
ejemplo relacionado con la herencia para clarificar las cosas.
Por último, el modificador sealed se usa para evitar que una clase pueda ser heredable. Si especificamos una clase sealed como
clase base en una herencia, obtendremos también un error de compilación. Por motivos obvios, una clase sealed no puede ser
además abstract. Para los amantes de los detalles técnicos, también diré que se produce una cierta optimización en tiempo de
ejecución al tratar con instancias de clases sealed, ya que debido a que una clase sealed nunca tendrá clases derivadas, se pueden
transformar las llamadas virtuales a funciones a llamadas no virtuales, con el consiguiente beneficio.

Primer acercamiento a la herencia.
Para que veamos unos ejemplos sobre lo hablado anteriormente en cuanto a clases abstractas y clases sealed, vamos a "iniciarnos"
un poco en el tema de la herencia. La herencia, ya lo he dicho al principio, es uno de los tres principios básicos de la POO. ¿Por
qué?. Pues porque permite clasificar jerárquicamente las clases creando una clase general que defina las partes comunes y que
esta clase sea heredada después por otras que, a su vez, añadirán más características propias. En C#, a la clase heredada se le
denomina clase base y a la que hereda, clase derivada. Ésta última puede ser clase base de otras. De ahí la estructura jerárquica.
Recordad que una clase derivada hereda todos los componentes (miembros) de la clase base. Veamos como se implementa la
herencia en C#:

class A
{ miembros_de_la_clase_A}

class B
{miembros_de_la_clase_B}

Fijaros en los dos puntos en la definición de la clase derivada (B). Eso indica que la clase B hereda de la clase A todos sus
miembros. En el Listado 1, vemos un ejemplo simple de herencia. Definimos la clase base con un entero y un método que se
encarga de imprimir su valor. De forma similar, en la clase derivada definimos otro entero y su método análogo al de la clase base.
Si ejecutáis el programa comprobaréis que desde un objeto creado a partir de la clase derivada (el objeto c1), accedemos a
modificar el valor de variable1 que estaba en la clase base , entre otras cosas por estar definida la variable como public, pero
sobre todo por estar también en la clase derivada gracias a que se ha heredado. Si no la hubiésemos heredado, no podríamos
haber accedido a variable1 desde un objeto de la clase Clase_derivada. Además, desde c1, ejecutamos el método

escribe_variable1(). La razón es la misma que antes: la clase derivada lo ha heredado.

Figura 1

Como dato curioso y aún no comentado, vemos en el resultado de la ejecución (Figura 1) que variable2 vale cero. Pero.....
nosotros no la hemos inicializado ¿verdad?. Cierto, pero ese es el comportamiento por defecto. Probad con variables de tipo string
y de otros tipos y comprobad los valores por defecto ;-)

Bien, pues ahora ya podemos poner un ejemplo sobre lo que hablábamos sobre las clases abstractas. Supongamos la siguiente
situación:

abstract class ClaseA {
public abstract void M();
}

Se trata de una clase abstracta por su modificador y además vemos que efectivamente está incompleta ya que el método no está
escrito, sólo declarado. Bien, pues si ahora queremos heredar de ClaseA (no, no tiene nada que ver con los vehículos, lo juro
jejeje) tenemos que implementar obligatoriamente el método M, o sino, la clase que vamos a construir deberá ser también
abstracta. Es decir, esta opción:

abstract class ClaseB: ClaseA {
public void hola() { Console.WriteLine("Hola");}
}

con lo cual seguimos teniendo una clase abstracta que ha heredado de la anterior y además ha implementado un método hola(). O
esta otra opción:

class ClaseC: ClaseA {
public override void M() {
/// lo que sea que haga M()
}
public void hola() { Console.WriteLine("Hola");}
}

que ya no es obligatoriamente abstracta debido a que implementa el método M() que era el único miembro que no lo estaba. Os
habréis dado cuenta que para hacerlo, hemos utilizado el modificador "override". Lo hemos dicho al principio: Los miembros
abstractos deben ser sobre-escritos (override) para ser implementados por la clase derivada que queremos que sea no abstracta.
Por supuesto, nada nos habría impedido haber hecho esto otro al definir la ClaseC:

class ClaseC: ClaseB {
public override void M() {
/// lo que sea que haga M()
}
}

Constructores: El método de inicialización
En casi todos los ejemplos y programas que hemos visto hasta ahora inicializábamos los valores de las variables de instancia en la
propia clase en la declaración ó desde un objeto de la instancia correspondiente. Esto no es lo más aconsejable en ningún lenguaje
orientado a objetos ya que podríamos incurrir en errores difíciles de detectar, como por ejemplo, olvidar inicializar un campo de
la clase. Como ya hemos visto, hay una inicialización por defecto en estos casos y podría provocar resultados inesperados. Para
esto (y otras cosas más) tenemos los constructores. El objetivo de un constructor es inicializar un objeto cuando se crea: Asignar
valores iniciales y también realizar procesos necesarios para la "existencia" del objeto que se crea. El nombre de un constructor es
el mismo que el de su clase y se define "casi" como un método. El acceso a un constructor suele ser public ya que se les llama
habitualmente desde fuera de la clase que "construyen", pero no es imprescindible. Por otra parte, siempre existe un constructor
en una clase aunque no lo definamos. Recordad que ya lo comentamos: todas las clases heredan de la object y por lo tanto
también su constructor (no exactamente así, sino que se asigna un constructor por defecto). Este constructor "por defecto" es el

que inicializa a cero las variables miembro de tipo valor y a null las de tipo referencia (vaya!! ya he dicho lo que tenías que haber
averiguado vosotros probando). En Listado 2 tenéis un ejemplo de un constructor sencillo y en la Figura 2 el resultado de
ejecutar el programa.

Por supuesto, un constructor puede incluir parámetros. Los parámetros se especifican en el método constructor tal y como ya
hemos visto en ocasiones anteriores. Mirad ésto:

Figura 2

class punto {
public double x, y ;
public punto(double x, double y)
{ this.x = x;
this.y = y; }
}

Tenemos un constructor que admite dos parámetros:exactamente las coordenadas del punto a crear. Ahora bien, también es posible
que deseemos tener la posibilidad de crear un objeto de la clase punto sin necesidad de darle las coordenadas. Uhmm.... probemos
a definir dentro de la clase punto, este otro constructor:

public punto() {
this.x = 0;
this.y = 0;
}

Vaya, ahora tenemos dos constructores!!. Uno acepta dos parámetros que definen sus coordenadas, el otro, simplemente, inicializa
éstas a cero. ¿Es posible tener dos ó más constructores?. Claro que sí. No sólo es posible con los métodos constructores, sino con
cualquier método. Esto es lo que se llama "sobrecarga" y ya ahondaremos en ello más adelante. De momento, ya sabemos como
crearnos constructores "a medida" de nuestras necesidades. Bien, y ahora que conocemos los constructores y l