Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Look up keyword
Like this
52Activity
0 of .
Results for:
No results containing your search query
P. 1
Lo que todo desarrollador debería saber sobre eventos en .NET

Lo que todo desarrollador debería saber sobre eventos en .NET

Ratings: (0)|Views: 4,209 |Likes:
Published by Krasis Press
¿Crees que lo sabes todo sobre los eventos? Este artículo te enseñará todo lo que debes conocer acerca de crear tus propios eventos en clases .NET con C#, teniendo en cuenta posibles problemas que probablemente no te hayas planteado. Indispensable.
¿Crees que lo sabes todo sobre los eventos? Este artículo te enseñará todo lo que debes conocer acerca de crear tus propios eventos en clases .NET con C#, teniendo en cuenta posibles problemas que probablemente no te hayas planteado. Indispensable.

More info:

Published by: Krasis Press on Nov 29, 2009
Copyright:Attribution Non-commercial Share Alike

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF or read online from Scribd
See more
See less

07/04/2014

pdf

 
 
Lo que tododesarrolladordebería sabersobre eventos en.NET
 
Rodrigo Corral
 
 
LO QUE TODO DESARROLLADOR DEBERÍA SABER SOBRE EVENTOS EN.NET
Nivel: Intermedio 
 
por
Rodrigo Corral
 La manera que las clases tienen de alertar a otras clases en los lenguajes orientados a objetosmodernos es lanzar eventos. Una clase que no expone eventos hace mucho más ardua la tareade los desarrolladores que la consumen a la hora de detectar cambios en su estado.
Una clasesin eventos es una clase incomunicada
.En un sentido amplio se podría decir que toda clase que diseñemos y que mantenga un estadodebería tener eventos. Si una clase mantiene estado es evidente que ese estado va a cambiar alo largo del ciclo de vida de los objetos que instanciemos. Es evidente también que si noexponemos eventos, quien quiera enterarse de los cambios en el estado no tendrá más opciónque preguntar activamente a nuestro objeto, en lugar de esperar plácidamente a recibirnotificaciones. Nada nuevo bajo el sol, el viejo conocido 
. Los eventos son imprescindibles y en .Net son ciudadanos de primera categoría (no ocurre así en otros lenguajes como C++). Aun así, no es extraño ver malas implementaciones de eventos.Es un tema que muchos desarrolladores creen conocer bien y sin embargo se ven a menudoerrores relacionados con la mala implementación de este concepto. Y es que
implementarbien un evento tiene más arte del que podría parecer y se pueden cometer más errores delos que uno puede pensar
. Éstos varían en gravedad desde simplemente complicar la vida a lasclases que deriven de la nuestra que expone eventos, hasta introducir condiciones de carreradifíciles de diagnosticar, pasando por simples incorrecciones de estilo. Lo peor de caso es que,por la propia naturaleza de estos errores, 
 no es capaz de avisarnos de ellos.
Un evento simple
Vayamos al grano y veamos la implementación más simple posible de un evento en .Net.Los que hemos vivido los tiempos de .Net 1.0 y 1.1 sabemos que la palabra clave
event 
solo es
“azúcar sintáctico” que prov
oca que el compilador emita por nosotros un delegado y en lostiempos de 1.x nosotros mismos teníamos que declarar el tipo de delegado a mano. Se trata deun evento que ni siquiera implementa su propia clase de argumento para el evento. Sería algocomo se muestra a continuación:
class Publisher  {public event EventHandlerSampleEvent; public voidFunctionThatProducesTheEvent() {SampleEvent(this,EventArgs.Empty); }}
 
 ¿Cuántos errores puede ver en
esta implementación? Uno, dos, tres… si no les ves sigue
leyendo.
¿Qué pasa si no hay nadie escuchando?
Generalmente, en una conversación, para que se produzca una comunicación correcta debehaber una parte emitiendo y otra recibiendo. En .Net una clase que quiera escuchar loseventos de otra simplemente tiene que subscribirse a ellos:
class Subscriber  {private Publisher_publiser =new Publisher(); publicSubscriber(){_publiser.SampleEvent +=new EventHandler(_publiser_SampleEvent); }void_publiser_SampleEvent(objectsender,EventArgse) {Console.Write("Habemus evento"); }}
Como ya hemos comentado lo eventos se implementan, simplificando el asunto, comodelegados. Simplificando otro poco podemos decir que los delegados son la versión orientadaa objetos de los punteros a función. Básicamente la clase que declara el evento es declarandoun tipo de puntero a función y un lugar en el que almacenar ese puntero. La clase que sesubscribe proporciona la función que realmente se ejecutará mediante un puntero a la funcióndurante la subscripción. Cuando la clase que lanza el evento hace la llamada al mismo(
SampleEvent 
en el ejemplo), simplificando, está llamando a una función a través de unpuntero. Por pura lógica si nadie se ha subscrito al evento dicho puntero será nulo, por lotanto invalido, y en consecuencia recibiremos una fea excepción de tipo
System.NullReferenceException
.La moraleja:
siempre debemos comprobar que alguien se ha subscrito a nuestro eventoantes de lanzarlo
. Más simple no puede ser:
class Publisher  {public event EventHandlerSampleEvent; public voidFunctionThatProducesTheEvent() {//Comprobar que tenemos subcriptores if(SampleEvent !=null) SampleEvent(this,EventArgs.Empty); }}

Activity (52)

You've already reviewed this. Edit your review.
Ori Kun liked this
1 thousand reads
1 hundred reads
Gustavo liked this
kinemalex liked this
Jorge Gil liked this
sirwalas liked this
jaimesun liked this

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->