PDF de programación - Delegados y eventos

Delegados y eventosgráfica de visualizaciones

Actualizado el 23 de Julio del 2021 (Publicado el 17 de Julio del 2017)
672 visualizaciones desde el 17 de Julio del 2017
173,5 KB
6 paginas
Creado hace 17a (22/09/2006)
Guillermo “Guille” Som

dnm.inicio.fundamentos
dnm.incio.fundamentos

Delegados y eventos
Primera parte: ¿En quién delegas tú?

En este número vamos a tratar de los delegados,y también de los eventos (aunque de
estos últimos nos encargaremos con más detalle en el próximo artículo), ya que en
.NET están estrechamente relacionados;tanto es así que no podemos definir un even-
to sin la intervención de un delegado.

<< Delegados y eventos en Visual Basic y C#

Seguramente los programadores de Visual Basic
estarán pensando que lo dicho en la entradilla no es
totalmente cierto. Bueno, posiblemente no, porque
si están leyendo dotNetManía sabrán lo que se escon-
de tras los eventos. Pero no está de más aclararlo para
que no queden dudas.

Lo cierto es que Visual Basic es un lenguaje muy
protector, y nos “libera” de ciertas tareas para facili-
tarnos el trabajo real, de forma que nos podamos con-
centrar en lo que de verdad importa y olvidarnos un
poco de ciertos “asuntillos” que en parte solo nos
hacen teclear más.

Aclaremos un poco todo esto que acabo de comen-
tar. En Visual Basic, para definir un evento solo hay que
escribir la instrucción Event seguida de la definición que
daremos al método que recibirá los eventos. Por ejem-
plo, si nuestra clase es del tipo Button, podemos definir
el evento Click de la siguiente forma:

Public Event Click( ByVal sender As Object,_

ByVal e As EventArgs )

Guillermo “Guille” Som
es Microsoft MVP de Visual Basic
desde 1997.Es redactor de
dotNetManía,miembro de Ineta
Speakers Bureau Latin America,
mentor de Solid Quality Learning
Iberoamérica y autor del libro
Manual Imprescindible de
Visual Basic .NET.
http://www.elguille.info

Como podemos comprobar, esa es la definición
que usaremos en cualquier formulario que quiera
interceptar la pulsación en un botón. Simple, ¿ver-
dad? Veamos ahora cómo tendría que definir ese mis-
mo evento un programador de C#:

public delegate void ClickEventHandler(

object sender, EventArgs e);

public event ClickEventHandler Click;

En este caso, primero se define un delegado y a
continuación hay que definir el evento que debe ser
del tipo de ese delegado. Complicado, ¿verdad? Ahora
mismo no entraremos en muchos detalles sobre esto,
antes veamos cómo se lanzaría ese evento tanto des-
de Visual Basic como desde C#:

' En Visual Basic:
RaiseEvent Click(sender, e)

// En C#:
if( Click != null )
{

Click(sender, e);

}

Indudablemente en Visual Basic sigue siendo mucho
más fácil, más simple, menos complicado, no tenemos
que comprobar nada... Y es cierto, a eso es a lo que me
refería con lo de que Visual Basic es muy “protector” y
nos libera de ciertos detalles que en realidad no nece-
sitamos saber, o al menos, no es obligatorio que sepa-
mos. Por otra parte a los programadores de C#, segu-
ramente por aquello de que les gusta “escribir más”
código, pues... ¡que escriban más! Aunque, como vere-
mos en este artículo, eso ya está cambiando, y ahora
podrán hacer también ciertas cosas sin necesidad de
escribir tanto, ya que el propio compilador de C# se
encargará de algunos aspectos, digamos, de trasfondo.
Pero al final, tanto C# como Visual Basic deben seguir
las reglas de .NET, y aunque nosotros como usuarios
no tengamos que preocuparnos, los compiladores sí que
lo harán.

Independientemente de las bromas,
tenemos que ser conscientes (sobre todo
los programadores de Visual Basic) de
que algunas veces el que nos “mimen”
tanto no es bueno, ya que nos acostum-
bran mal, y cuando creemos que todo
va a ser sencillo, llega la versión 2005 y
nos dicen que si queremos usar la nue-
va instrucción Custom Event debemos
saber manejar los delegados, además de
que también debemos saber en qué
medida están relacionados con los even-
tos. Esto a los programadores de C# no
les pillaría tan desprevenidos. Así, si aho-
ra les dicen que pueden crear métodos
anónimos, y que esos métodos anóni-
mos los podrán crear donde se pueda
usar un delegado, o que ya no es nece-
sario usar un constructor para crear un
tipo delegado o que por medio de la
covarianza o la contravarianza podrán
usar de forma más óptima los delega-
dos, simplemente estarán preparados y
sabrán soportar el cambio...

Pero como siempre hay gente nue-
va, (tanto en C# como en Visual Basic),
no está de más que algunos puntos estén
totalmente claros, así que eso es lo que
vamos a intentar en este primer artícu-
lo dedicado a los delegados y a los even-
tos. Y en los que seguirán, terminare-
mos por aclarar casi cualquier duda que
posiblemente se nos pueda presentar a
la hora de trabajar con los eventos y con
los delegados.

¿Qué son y para qué sirven los
delegados?

Como sabemos, .NET Framework
se caracteriza por ser un entorno de
código administrado (managed code) o lo
que es lo mismo, a .NET no le gustan
las sorpresas. Si una función tiene que
devolver un valor de tipo String, debe
devolver un valor de tipo String; si un
método debe recibir dos parámetros de
tipo Object, eso es lo que recibirá. Y
todo esto los lenguajes adscritos a .NET
deben respetarlo, ya que de no ser así,
.NET no permitirá la ejecución del
código. Y esto es aplicable a todo lo que
.NET controla, es decir, a todo lo que
está bajo su influencia. Lo que no quie-
re decir que no podamos hacer cosas que
.NET no permita; pero si lo hacemos,
debemos hacerlo por la puerta falsa. De

<<

dnm.inicio.fundamentos

esto saben mucho los que han desarro-
llado con C, incluso los que desarrollan
con C#. Aunque en todas las puertas fal-
sas de .NET siempre hay alguien que
“está por allí” y revisa que en realidad
no hagamos demasiadas trastadas. Esto
en otros lenguajes no es así, y por error
o porque así lo hayamos previsto, pode-
mos crear grandes problemas, si no, ¿por
qué aparecen los fallos de protección
general? (las típicas pantallas azules de
las versiones anteriores de Windows,
que ahora simplemente están remoza-
das y han cambiado de look por un cua-
dro de diálogo más “mono”).

arbitrario, es decir, que no nos “cole-
mos” donde no debemos, ya que, como
ya he dicho, a .NET no le gustan las
sorpresas, por eso impone reglas que
debemos cumplir; si las cumplimos,
pasamos, si no las cumplimos, no nos
deja seguir.

Y esto es así por todo lo comentado
anteriormente, ya que el CLR quiere
seguridad y la única forma de tenerla es
creando normas de conducta y de utili-
zación, en este caso, de la memoria o del
acceso a esas partes de la memoria en la
que están las definiciones de los méto-
dos o funciones.

Un delegado permite acceder a una función de
forma casi anónima,ya que simplemente tiene la

dirección de memoria de dicha función

Este tipo de problema se debe a un
acceso indebido a la memoria, normal-
mente causado por un acceso a una posi-
ción de memoria que no estaba dentro del
rango que teníamos permitido. .NET es
más estricto y menos permisivo para estas
cuestiones, por tanto, si queremos estar
bajo el abrigo de la seguridad de .NET
debemos seguir sus normas.

Como sabemos, .NET define una
serie de tipos de datos, los cuales pode-
mos usar indistintamente desde un len-
guaje u otro, ya que independientemen-
te del nombre que cada compilador le
dé, en realidad estamos trabajando con
los tipos definidos en la librería de cla-
ses, o mejor dicho, en el sistema de tipos
comunes (CTS). Y los delegados no son
una excepción.

Pero... ¿qué es un delegado? Un
delegado es una referencia a una fun-
ción, lo que también se conoce como un
puntero a una función, es decir, un dele-
gado permite acceder a una función de
forma casi anónima, ya que simplemen-
te tiene la dirección de memoria de
dicha función. Y sabiendo la dirección
de memoria, podemos acceder a ella.
Pero en .NET esto debe estar contro-
lado, de forma que ese acceso no sea

Por tanto, si queremos acceder a un
método, tenemos que hacerlo por medio
de un puntero controlado, y la forma de
controlar ese acceso es definiendo un
prototipo en el que indiquemos de qué
tipo es ese método, si recibe paráme-
tros, y de hacerlo cuántos y de qué tipo
son. Una vez que tenemos definidos
todos estos requerimientos, es cuando
le decimos al runtime de .NET que nos
permita acceder a esa función. De esta
forma, podrá controlar que estamos
accediendo al sitio correcto.

Esa definición del prototipo de fun-
ción (o método) al que queremos acce-
der lo hacemos por medio de un delega-
do. Podemos pensar que un delegado es
en cierto modo similar a las interfaces (ver
dotNetManía nº 16), que como sabemos
definen un contrato que debemos respe-
tar. Sabiendo esto, si queremos acceder a
una función que devuelve una cadena y
que recibe un parámetro de tipo Cliente,
debemos definir un delegado con esas
características, y cuando posteriormente
queramos acceder a ese método, en lugar
de hacerlo directamente o por medio de
un puntero directo, usaremos un objeto
del tipo definido por el delegado. Lo que
nos lleva a una segunda definición de lo

a
í
n
a
M
t
e
N
t
o
d

<
<

43

<<

dnm.inicio.fundamentos

Los delegados definen la “firma” que los métodos

a los que queremos acceder deben tener

gado. Veamos el siguiente código y segu-
ro que esa cercanía no es tan necesaria:

public static void usarMiFuncionDelegado(
MiFuncionDelegado mfd)

{

}

string s = mfd( new Cliente() );

que es un delegado, en la que podemos
decir que es un tipo especial que nos per-
mite definir la forma de acceder a una
función.

Veamos el ejemplo del método que
devuelve una cadena y recibe un paráme-
tro de tipo Cliente. Ese método lo pode-
mos definir en C# de esta forma:

public string MiFuncion(Cliente c)

{return “...”;}

La forma de usar ese método sería

algo así:

string s = MiFuncion( new Cliente() );

Por supuesto aquí no estamos usan-
do ningún puntero, simplemente esta-
mos accediendo a ese método de forma
directa. Es más, debido a que no esta-
mos indicando dónde está dicha fun-
ción, suponemos que estamos accedien-
do desde la propia clase en la que está
definido. Pero si quisiéramos acceder
de una forma más anónima, podríamos
definir un
  • Links de descarga
http://lwp-l.com/pdf5510

Comentarios de: Delegados y eventos (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