PDF de programación - Curso 2014 Un truco de magia

Imágen de pdf Curso 2014 Un truco de magia

Curso 2014 Un truco de magiagráfica de visualizaciones

Publicado el 19 de Abril del 2017
744 visualizaciones desde el 19 de Abril del 2017
458,7 KB
9 paginas
Creado hace 9a (11/11/2014)
Introducción
En esta práctica vamos a hacer un truco de magia. En serio, también con la
programación podemos hacer trucos de magia. Pero lo más interesante de nuestro
truco de magia es que vamos a aprender un poco más sobre el funcionamiento interno
de los middleware modernos.

Curso de Middleware. Práctica Truco de magia
1 de 9

Truco de magia
Abre el proyecto que acompaña la práctica con el Visual Studio. Cuando lo abras
tendrás que ver lo siguiente:

Primero observa que tenemos una clase como cualquier otra. Esta clase tiene métodos
definidos y una propiedad (“Fortune”).

Curso de Middleware. Práctica Truco de magia
2 de 9

. . .

/// <summary>
/// Esta es un metodo de ejemplo para hacer el
/// tipico hola mundo
/// </summary>
/// <param name="name">
/// A <see cref="System.String"/>
/// </param>
public void Saluda (string name)
{
Console.WriteLine ("Hola {0}", name);

}

. . .

// si quieres ver algo interesante, llamame
public string Fortune
{

get { return "No tienes nada que hacer"; }

}

. . .

Por otra parte, observa que tenemos un programa principal que crea un objeto de dicha
clase y que llama a los métodos existentes.

. . .
UnaClaseDePrueba obj = new UnaClaseDePrueba ();

obj.Saluda ("A mis alumnos");

Console.WriteLine( "Fortune me dice que :" + obj.Fortune);

. . .

Nada raro por ahora, ¿verdad?
Bien, vamos a ejecutar la aplicación y a analizar el resultado obtenido por pantalla. Si
todo es correcto deberíamos ver algo parecido a:

Curso de Middleware. Práctica Truco de magia
3 de 9

¿Observas algo irregular? ¿No?
Mira con más atención lo que nos ha devuelto la llamada al método Fortune. Es cierto
que es una propiedad, un get, pero sigue siendo un método y lo que retorna es
claramente “No tienes nada que hacer” pero en pantalla nos aparece un texto bien
diferente. ¿Magia?
Intenta cambiar el texto que debe retornar Fortune. ¿Has conseguido algo?
Bueno, dejemos por el momento este método y vamos a escribir un método propio.
Para no influir en tu decisión, te dejo que elijáis el nombre del método y el valor que
retorna (puede optar por no devolver nada). Desde el programa principal llama a ese
nuevo método.
En mi caso me he creado un método llamado “void MiMetodoNuevo()” y esto es lo
que veo al volver a ejecutar la aplicación.

Curso de Middleware. Práctica Truco de magia
4 de 9

Es decir, la aplicación acaba de averiguar cuál es el método recién creado. Es como
cuando eliges una carta y el mago adivina cuál has elegido. ¿Magia de nuevo?

Bueno, vamos a seguir jugando. Ahora os propongo un nuevo cambio. Vamos a
definir un constructor que algún parámetro (sobre todo para no coger el constructor
por defecto). Modificar el ejecutable principal para que al construir el objeto sea
coherente. Al ejecutar vuestro ejemplo deberéis ver algo parecido a:

Y de nuevo la aplicación genera trazas que no estaban previstas.
¿Dónde está el truco? ......

Curso de Middleware. Práctica Truco de magia
5 de 9

Os dejo averiguarlo por vuestra cuenta. Según veáis cosas que os parezcan
interesantes podemos ir discutiéndolo en clase.

Curso de Middleware. Práctica Truco de magia
6 de 9

Ejercicios adicionales

Os proponemos varios ejercicios que nos ayuden a entender el truco de magia. No los
realices hasta haber completado y discutido sobre el punto anterior. Intenta lo
siguiente:

1. Define un método estático y desde el programa principal intenta llamarlo.

¿Qué ha pasado?

2. Comenta la línea de dice “[Middleware]”. Vuelve a ejecutar la aplicación y

analiza lo sucedido.

3. Quita la herencia de la clase “UnaClaseDePrueba”. Vuelve a ejecutar la

aplicación y analiza lo sucedido.

4. Mira las referencias que están incluidas en el proyecto.

¿Te dice algo la siguiente pista?

Curso de Middleware. Práctica Truco de magia
7 de 9

Explicando el truco de magia

Muchas de los elementos involucrados en esta práctica los veremos más adelante en el
curso. Pero el más importante es que hemos dado el primer paso para entender las
técnicas que hay detrás de un concepto interesante: “La programación Orientada a
Aspectos (AOP)”. Realmente no hemos hecho AOP, pero hemos utilizado la magia
que suele haber detrás.
La explicación de nuestro truco es que C# y .Net tiene dos tipos de objetos. Los
objetos habituales (también llamados “ágiles”) que usamos día a día y los objetos
sensibles al contexto (“ContextBound”). Éstos últimos son diferentes a los ágiles en
que el sistema permite interceptar todas las llamadas que se produzcan hacia estos
objetos. Esta capacidad es muy útil en algunas situaciones. Por ejemplo, se puede
utilizar para hacer Programación Orientada a Aspectos (AOP). En sucesivas prácticas
veremos cómo funciona la interceptación de métodos.
Cuando decimos que un objeto es “MarshalByRefObject” estamos indirectamente
diciéndole al sistema que los objetos serán interceptados. Esta capacidad de
intercepción la utiliza Remoting para enlazar y apilar una serie de clases de tal forma
que puede hacer cosas antes o después de la llamada. Por ejemplo, si el objeto es
local, .Net Remoting intercepta la llamada pero la deja pasar sin hacer nada especial,
con lo que desde nuestra aplicación no observamos nada diferente. En cambio, si el
objeto es remoto, .Net Remoting intercepta la llamada, formatea los datos para ser
transmitidos (“serializa” los datos) y llama al objeto remoto. La llamada, en ese caso,
nunca termina ejecutando el código local. Esto lo hemos visto en el último ejercicio.
En este ejercicio se producía una llamada a una función que debería haber provocado
una excepción, pero que no se llegaba a generar.
.Net Remoting sitúa detrás de la llamada una cadena de llamadas que se apilan. Cada
nivel de esa pila se encarga de una función específica: formatear los datos, la
transmisión usando un protocolo específico, seguridad, encriptación, etc. Esta pila de
clases se denominan sumideros (“sink”), cuyo agrupamiento se denomina canal
(“channel”). Gráficamente, el funcionamiento se podría representar por:

Curso de Middleware. Práctica Truco de magia
8 de 9

Esta arquitectura nos permite modificar o ampliar el funcionamiento por defecto de
.Net Remoting. Es posible añadir o modificar los sumideros existentes de tal forma
que es posible hablar con sistemas IIOP (Rmi o Corba). En Internet existe una gran
cantidad de canales específicos para aplicaciones muy concretas. Se propone al
alumno que busque y pruebe alguno de esos canales (SMTP, TCP bidereccional, etc.).

Espero que hayáis disfrutado de nuestro truco de magia!!! :-)

Curso de Middleware. Práctica Truco de magia
9 de 9
  • Links de descarga
http://lwp-l.com/pdf3128

Comentarios de: Curso 2014 Un truco de magia (0)


No hay comentarios
 

Comentar...

Nombre
Correo (no se visualiza en la web)
Valoración
Comentarios...
CerrarCerrar
CerrarCerrar
Cerrar

Tienes que ser un usuario registrado para poder insertar imágenes, archivos y/o videos.

Puedes registrarte o validarte desde aquí.

Codigo
Negrita
Subrayado
Tachado
Cursiva
Insertar enlace
Imagen externa
Emoticon
Tabular
Centrar
Titulo
Linea
Disminuir
Aumentar
Vista preliminar
sonreir
dientes
lengua
guiño
enfadado
confundido
llorar
avergonzado
sorprendido
triste
sol
estrella
jarra
camara
taza de cafe
email
beso
bombilla
amor
mal
bien
Es necesario revisar y aceptar las políticas de privacidad