using System;

public class Base { public void MetodoNormal () {

Console.WriteLine (“Soy Base.MetodoNormal ()”);} public virtual void MetodoVirtual () { Console.WriteLine (“Soy Base.MetodoVirtual ()”);}

}

public class Heredada : Base {

new public void MetodoNormal () {

Console.WriteLine (“Soy Heredada.MetodoNormal ()”);

}

public override void MetodoVirtual () {

Console.WriteLine (“Soy Heredada.MetodoVirtual ()”);

}

static void Main () {

Heredada claseHeredada = new Heredada ();

Base claseBase = claseHeredada;

claseBase.MetodoNormal ();

claseHeredada.MetodoNormal ();

claseBase.MetodoVirtual ();

claseHeredada.MetodoVirtual (); 

}

}

Si lo ejecutamos obtenemos lo siguiente:

Soy Base.MetodoNormal ()

Soy Heredada.MetodoNormal ()

Soy Heredada.MetodoVirtual ()

Soy Heredada.MetodoVirtual ()

Nótese como algo extraño sucede en la tercera línea. Mientras que en el código fuente la llamada se hace a la clase Base, el resultado es el de la clase heredada, cosa que no ocurre con el “método normal”. La culpa de este comportamiento la tiene la combinación de las palabras clave virtual y override, que declaran y redefinen respectivamente a los métodos virtuales. En este caso el método escogido no se corres­ponde con el que observa en el momen­to de la compilación, sino en el momento de la ejecución. Debemos fijarnos en que la definición de la instancia de la clase base se hace en términos de la clase heredada al comienzo del método principal. Vemos entonces como override hace un papel análogo a new, solo que se ocupa de métodos virtuales, que pueden variar la funcionalidad incluso de las clases bases.  Si la declaración de las instancias las cambia­mos por las siguientes:

Base claseBase = new Base ();

Heredada claseHeredada = new Heredada ();

Todo funcionará sin diferencias. Los métodos virtuales se comportarán como los demás. Lo divertido sucede cuando volvemos a considerar más de dos clases. ¿Qué ocurrirá en el siguiente ejemplo? using System;class A {public virtual void Metodo () {

Console.WriteLine (“Yo soy A.Metodo ()”);

}

}

class B : A {

public override void Metodo () {

Console.WriteLine (“Yo soy B.Metodo ()”);

}

}

class C : B {

new public virtual void Metodo () {

Console.WriteLine (“Yo soy C.Metodo ()”);

}

}

class D : C {

public override void Metodo () {

Console.WriteLine (“Yo soy D.Metodo ()”);

}

static void Main () {

D d = new D ();

A a = d;

B b = d;

C c = d;

a.Metodo ();

b.Metodo ();

c.Metodo ();

d.Metodo ();

} 

}

Hemos usado todas las combinaciones posibles. Primero declaramos un método vir­tual, luego lo redefinimos con override. En C se usa new y se vuelve a emplear virtual, y en D se cierra el ciclo y se utiliza de nuevo overri­de. A continuación creamos una instancia de la clase más baja en el nivel de herencia, y el resto de las instancias las hacemos depender de ella. Como siempre, termina­mos llamando a todos los métodos. ¿Qué ocurrirá? Si hemos seguido el razonamiento hasta aquí, encontraremos rápidamente la respuesta: las clases que contengan méto­dos virtuales perderán su funcionalidad y las demás no. El problema está en a.Metodo() ya que tenemos dos opciones, o bien se queda con el método de B o bien salta hasta D que es la instancia activa. El resultado final es el siguiente, esto es, la clase que se ocupa de la implementación es la más cercana en el árbol de herencias:

Yo soy B.Metodo ( )

Yo soy B.Metodo ( )

Yo soy D.Metodo ( )

Yo soy D.Metodo ( )

using System;

public class Base {

public static void MetodoBase () {

Console.WriteLine (“Yo soy Base.MetodoBase ()”);

}

}

public class Heredada : Base {

public static void Main () {

MetodoBase ();

}

new public static void MetodoBase () {

Console.WriteLine (“Yo soy Heredada.MetodoBase ()”);

}

}

Tenemos dos clases, donde una hereda de la otra. La segunda además redefine el método MetodoBase() gracias al modifica­dor new. Al ejecutar el programa, se vería lo siguiente:

Yo soy Heredada .MetodoBase ( )

lo que verifica que la redefinición ha sido un éxito. Si eliminamos el parámetro new el pro­grama seguiría compilando, pero obtendría­mos una advertencia:

New. cs ( 18 ) warning CS0108 :The keyword new is required on‘ Heredada . MetodoBas e ‘ because it hides inherited member‘ Base .MetodoBase ‘ Compilation succeeded – 1 warning(s) s ) 

El compilador nos ayuda a no ocultar métodos sin querer. Igualmente, si la clase Base no tuviera ninguna definición para MetodoBase(), el compilador también nos advertiría de que no estamos redefiniendo nada.  Todo esto se puede complicar un poco más. Supongamos que tenemos una clase B que hereda de A, y una clase C que here­da de B. Pues bien, es posible redefinir un método de A en B, sin que C note el cambio, teniendo lo siguiente: 

using System;

public class A {

public static void MetodoBase () {

Console.WriteLine (“Yo soy A.MetodoBase ()”); }

}

public class B : A {new prívate static void MetodoBase () {

Console.WriteLine (“Yo soy B.MetodoBase ()”);

public class C : B {

static void Main () {

MetodoBase ();}}

}

}

El método C imprimiría por pantalla “Yo soy A.MetodoBase ()” gracias a que en B hemos marcado la redefinición como priva­da, lo que la restringe a dicha clase. Si cam­biamos prívate por public, o hacemos la lla­mada dentro de B conseguiremos “Yo soy B.MetodoBase ()”. Tenemos una doble herencia anidada de clases en la que la ocul­tación de métodos es solamente parcial.

Continúa en Métodos Virtuales

using System;

class Parametros {

static void Main () {

int[] parametros = {l, 2, 3, 4, 5};

CuentaArgumentos (parametros);

CuentaArgumentos (1, 2, 3);

CuentaArgumentos ();

} 

static void CuentaArgumentos (params int[] parametros) {

Console.Write (“He recibido {O} argumentos:”, parametros.Length);

for (int i = O; i < parametros.Length; i++)

Console.Write (” {0}”, parametros[i]);

Console.WriteLine (); 

}

}

En el programa hemos definido un método llamado CuentaArgumentos al que le hemos añadido params en su definición. Esto nos permite invocarlo de tres maneras distintas en el método principal. Da igual si lo llamamos con un array como argumento, una lista de números o sencillamente nada. El método será capaz de controlar adecua­damente cada situación:He recibido 5 argumentos: 1 2 3 4 5 He recibido 3 argumentos: 1 2 3

He recibido O argumentos:

Cabe preguntarse qué pasaría si eliminá­ramos params de la definición, puesto que formalmente seguiría siendo correcta. El resultado es el esperado, tal como se muestra a continuación:

Params.cs (8) error CS1501: No overload for method ‘CuentaArgumentos’ takes ‘3′ arguments

Params.cs(8) error CS8006: Could not find any applicable functíon for this argument list

Params.cs(9) error CS1501: No overload for method ‘CuentaArgumentos’ takes ‘O’ arguments

Params.cs(9) error CS8006: Could not find any applicable function for this argument list

Compilation failed: 4 error(s), 0 warnings

Esto significa que puede que la definición del método sea válida, pero sus invocacio­nes no lo son.

Supongamos que necesitamos una función que divida en dos una palabra y devuelva los dos trozos resultantes. Pues bien, entonces haríamos lo que muestra en el siguiente código:

using System;

class Parametros {

static void Main () {

string izquierda, derecha;

string cadena = “Me van a cortar por la mitad”;

Console.WriteLine (“Cadena original = ‘{0}’”, cadena);

Divide (cadena, out izquierda, out derecha);

Console.WriteLine (“Primera parte = ‘{0}’”, izquierda);

Console.WriteLine (“Segunda parte = ‘{0}’”, derecha);

}

static void Divide (string cadena, out string izquierda, out string derecha) { izquierda = cadena.Substring (O, cadena.Length / 2);derecha = cadena.Substring (cadena.Length / 2);

}

}

Al ejecutarlo, daría el siguiente resultado por pantalla:  Cadena original = ‘Me van a cortar por la mitad’Primera parte = ‘Me van a corta’

Segunda parte = ‘r por la mitad’

El programa hace uso del método Substring, miembro de System.String que nos permite extraer fácilmente subconjun­tos de cadenas de texto. Como vemos, pese a que las cadenas izquierda y derecha no estaban inicializadas, el compilador no ha puesto ningún problema a que fuera el método Divide O el que realizará dicha asig­nación.

Si en lugar de out, hubiéramos emplea­do ref, habríamos obtenido el siguiente error de compilación: 

Divide.cs(10) error CS0165: Use of unassigned local variable ‘izquierda’ Divide .cs (13) error CS0165: Use of unassigned local variable ‘derecha’ Compilation f ailed: 2 error (s ) , O warnings

using System;class Parametros {

static void Main () {

int a = 2;

int b = 3;

int c = Suma (a, b);

Console.WriteLine (“{0} + {1} = {2}”, a, b, c);

}

static int Suma (int a, int b) {

return a + b; 

}

}

Se escriben el nombre de las variables a la hora de invocar el método, y cuando se define, la precedemos por su tipo. Así, al ejecutar el códi­go obtenemos: 

2 + 3 = 5

Por valor

Por referencia

Parámetros exteriores

Parámetros múltiples

using System;

class Parametros {

static void Main () {

int a = 2;

int b = 3;

Console.WriteLine (“a = {O}, b = {1}”, a, b);

Intercambia (a, b);

Console.WriteLine (“a = {O}, b = {1}”, a, b);

}

static void Intercambia (int a, int b) {

int temp = a;

a = b;

b = temp;

}  }Sin embargo, nos veremos contrariados al comprobar que el programa no ejecuta ninguna acción:

a = 2, b = 3

a = 2, b = 3

Lo que ha pasado es que las operacio­nes que hemos realizado con las variables dentro del método Intercambia o no han tenido efecto. Pese a que nosotros hemos asignado nuevos valores que intercambiaban los antiguos, todo ha seguido como al principio. Lo que ocurre es que el método no altera el valor de las variables originales, ya que trabaja sobre una copia de éstas. Precisamente esto es lo que se solucio­na con la llamada por referencia de paráme­tros. Si cambiamos la defini­ción del método por:static void Intercambia (ref int a, ref int b) {

…

}

y si, por consiguiente, lo invocamos inclu­yendo las palabras clave ref.

Intercambia (ref a, ref b);

el resultado ahora sí es el deseado:

a = 2, b = 3

 a = 3, b = 2

Al introducir ref como prefijo de invoca­ción dé los parámetros, evitamos el efecto que comentábamos al principio. Por lo tanto, lo que hagamos sobre las variables en el método, afecta a las variables originales.

A través de la programación estructurada se pueden unir secuencias de declaraciones e instrucciones en un mismo lugar. La inclusión de procedimientos hace a los programas estructurados y con menos posibilidad de errores.

La Programación Orientada a Objeto (POO) permite construir aplicaciones mas estables y de mayor tamaño. La estructura es organizada por los datos. Primero se seleccionan las representaciones de los datos que mejor cumplen los requerimientos para luego decidir que hacer con ellas. 

El objeto es algo con características o propiedades que se pueden ver, tocar y habrán una serie de acciones que describen su funcionabilidad.  

La clase es la construcción del lenguaje mas utilizado para definir los tipos de datos. 

Los métodos son las funciones asociadas a un objeto especifico. 

El mensaje es una petición de un objeto para la invocación de uno de sus métodos. Un mensaje contiene el nombre de un objeto o los argumentos del método. 

La Propiedad o característica es una asignación que describe algo sobre un objeto como un formulario.

El subsistema de ENTRADA/SALIDA (E/S) suministra al computador un mecanismo eficiente de comunicación entre el procesador central y el entorno exterior.

La conexión de dispositivos periféricos a un computador no puede llevarse a cabo de forma directa haciendo uso del bus del procesador, esta restricción es debida fundamentalmente a tres razones importantes:

– Existe una gran variedad de dispositivos con distintos modos de operación.

– El ritmo de transferencia de datos es, en casi todos los casos, mucho menor que hay entre la CPU y la memoria principal

.– En ocasiones, el periférico requiere que los datos le sean suministrados en formatos distintos al utilizado por la CPU.

La Interfaz de E/S de las aplicaciones es la que define el modelo de E/S que ven los usuarios, por lo que cuando se diseña el Sistema Operativo se debe tener en cuenta decisiones relativas a la funcionalidad que se va ha ofrecer al exterior: Nombres Independientes de los Dispositivos, E/S No Bloquean o Asíncronas, Control de Acceso a Dispositivos, Indicadores de Error y Uso de Estándares.

Para la realización de una operación de E/S el sistema operativo debe efectuar las siguientes funciones:

- Recuento de las unidades de información transferidas (normalmente bytes) para reconocer el fin de operación.

- Sincronización de velocidad entre la CPU y el periférico.

- Detección de errores (e incluso corrección) mediante la utilización de los códigos necesarios (bits de paridad, códigos de redundancia cíclica, etc.).

- Almacenamiento temporal de la información. Es más eficiente utilizar un buffer temporal específico para las operaciones de E/S que utilizan el área de datos del programa.

- Conversión de códigos, conversión serie/paralelo, etc.Las funciones que debe realizar un computador para ejecutar trabajos de entrada/salida son las siguientes:

- Direccionamiento o selección del dispositivo que debe llevar a cabo la operación de E/S.

- Transferencia de los datos entre el procesador y el dispositivo (en uno u otro sentido).

- Sincronización y coordinación de las operaciones.

Esta última función es necesaria debido a la diferencia de velocidades entre los dispositivos y la CPU y a la independencia que debe existir entre los periféricos y la CPU (por ejemplo, suelen tener relojes diferentes).

Se define una transferencia elemental de información como la transmisión de una sola unidad de información (normalmente un byte) entre el procesador y el periférico o viceversa. Para efectuar una transferencia elemental de información son precisas las siguientes funciones: 

- Establecimiento de una comunicación física entre el procesador y el periférico para la transmisión de la unidad de información. 

- Control de los periféricos, en que se incluyen operaciones como prueba y modificación del estado del periférico. Para realizar estas funciones la CPU gestionará las líneas de control necesarias.

Una forma de administración de un sistema de archivos dentro de un sistema operativo puede ser la siguiente:

Se utiliza una raíz para indicar en qué parte del disco comienza el directorio raíz. 

El directorio raíz apunta a los directorios de usuarios.

Un directorio usuario contiene una entrada para cada uno de los archivos del usuario. 

 Cada entrada de archivo apunta al lugar del disco donde está almacenado el archivo referenciado.

Cabe destacar que los nombres de archivos solo necesitan ser únicos dentro de un directorio de usuario dado. El nombre del sistema para un archivo dado debe ser único para el sistema de archivos.

En algunos sistemas de archivos los nombres de archivos son estructurados, con sintaxis especiales para extensiones de archivos y números de versión. En otros, los nombres de archivos son simplemente cadenas de texto y los metadatos de cada archivo son alojados separadamente.

En sistemas de archivos jerárquicos, en lo usual, se declara la ubicación precisa de un archivo con una cadena de texto llamada “ruta”. La nomenclatura para rutas varía ligeramente de sistema en sistema, pero mantienen por lo general una misma estructura. Una ruta viene dada por una sucesión de nombres de directorios y subdirectorios, ordenados jerárquicamente de izquierda a derecha y separados por algún carácter especial que suele ser una barra (‘/’) o barra invertida (‘\’) y puede terminar en el nombre de un archivo presente en la última rama de directorios especificada.

Los sistemas de archivos tradicionales proveen métodos para crear, mover y eliminar tanto archivos como directorios, pero carecen de métodos para crear, por ejemplo, enlaces adicionales a un directorio o archivo o renombrar enlaces padres.