You are currently browsing the tag archive for the ‘C#’ tag.

To implement an interface is to set up one contract between two code blocks, where the block that implements the interface is committed to implement specifically the methods defined by the interface.

At glance this sounds somehow weird. The question that arises is: Don’t I’m complicating my life? It depends…

Let’s suppose that, in the frame of a process, we have a heterogeneous set of objects that we unknown. Some have a serialization method named Save, if the method exists, then this is the responsible of the object persistence. If doesn’t exist such Save method, the object is persisted in the database by another method.

The question is how to find out, in runtime, if an object is implementing one method with a specific name? The following attempts to answer this. To develop that example, you will need to start Visual Studio and create one project of windows Console type for Visual Basic or C#.

Now we create the interface ISerializable, that contains the Save function that returns a boolean value:

[VB]

Public Interface ISerializable

Function Save() As Boolean

 End Interface

[C#]

using System;

interface ISerializable

{

bool Save();

}

By convention the names of the interfaces are prefixed with an “I” for better identification.

Then we are going to create one class, named PettyControl, with one unique property named Data of string type:

[VB]

Public Class PettyControl

Private mData As String

Public Property Data() As String

Get

Return mData

End Get

Set(ByVal value As String)

mData = value

End Set

End Property

End Class

[C#]

using System;

public class PettyControl

{

protected string Data;

public string data

{

get

{

return Data;

}

set

{

Data = value;

}

}

}

I define now one control, named myControl, that inherits from PettyControl and implements the ISerializable interface.

[VB]

Public Class myControl

Inherits PettyControl

Implements ISerializable

Public Sub New()

Data = “These are the test data…”

End Sub

Public Function Save() As Boolean

Implements ISerializable.Save

Console.WriteLine(“Saving…{0}”, Data)

Return True

End Function

End Class

[C#]

using System;

class myControl : PettyControl, IValidate, ISerializable

{

public myControl()

{

data = “These are the test data…”;

}

public bool Save()

{

Console.WriteLine(“Saving…{0}”, data);

return true;

}

}

In this way we have implemented the Save method of ISerializable interface. You will see that when typing the code line referred to the implementation of the interface, when you click on Enter, Visual Studio writes automatically the header of the function that the interface defines.

At this point, we know how to implement an Interface.

Now the problem is to know, programmatically, if one class implements some specific interface. For the example we are seeing, in concrete terms, is to know whether the class has implemented some Save method, in other words, if the class implements some serialization method.

So,we are going to write the application that will start in console, naming it App.

[VB]

Module App

Sub Main()

Console.WriteLine(“Visual Basic Version”)

Dim myControl As New myControl

Dim ser As ISerializable = DirectCast(myControl, ISerializable)

Dim success As Boolean = ser.Save

Console.WriteLine(“‘{0}’ Validation was{1}success.”, myControl.Data, IIf(success, ” “, ” not “))

End Sub

Console.ReadLine()

End Module

[C#]

class App

{

public static void Main()

{

Console.WriteLine(“C# Version”);

myControl myControl = new myControl();

ISerializable ser = (ISerializable)myControl;

bool success = ser.Save();

Console.WriteLine(“‘{0}’ Validation was{1}success.”, myControl.data, (success ? ” “ : ” not “));

}

Console.ReadLine();

}

This seems to work, but if the interface is not implemented “DirectCast(myControl, ISerializable)” in VB, or “(ISerializable)myControl” in C#, both in this case fail.

The correct way to ask is: “TypeOf (myControl) Is ISerializable”, in VB, or “myControl Is ISerializable” in C#. Let’s see:

[VB]

Module App

Sub Main()

Console.WriteLine(“Visual Basic Version”)

Dim myControl As New myControl

If TypeOf (myControl) Is ISerializable Then

Dim ser As ISerializable = DirectCast(myControl, ISerializable)

Dim anotherSuccess As Boolean = ser.Save

Console.WriteLine(“{0}’ Have{1}been successfully saved., myControl.Data, IIf(anotherSuccess, ” “, ” not “))

End If

Console.ReadLine()

End Sub

End Module

[C#]

class App

{

public static void Main()

{

Console.WriteLine(“C# Version”);

myControl myControl = new myControl();

if (myControl is ISerializable)

{

ISerializable ser = (ISerializable)myControl;

bool anotherSuccess = ser.Save();

Console.WriteLine({0}’ Have{1}been successfully saved., myControl.data, (anotherSuccess ? ” “ : ” not “));

}

Console.ReadLine();

}

}

This works fine in both languages. But there is an optimized way, in terms of MSIL.

In VB, “TryCatch” is used, which evaluates whether the interface is implemented, if doesn’t it, doesn’t return an error but instead Nothing. In C# this is analogous to the “as” operator.

[VB]

Module App

Sub Main()

Console.WriteLine(“Visual Basic Version”)

Dim myControl As New myControl

Dim serial As ISerializable = TryCast(myControl, ISerializable)

If Not serial Is Nothing Then

Dim anotherMoreSuccess As Boolean = serial.Save

Console.WriteLine(‘{0}’ Have{1}been successfully saved, with an optimized version., myControl.Data, IIf(anotherMoreSuccess, ” “, ” not “))

End If

Console.ReadLine()

End Sub

End Module

[C#]

class App

{

public static void Main()

{

Console.WriteLine(“C# Version”);

myControl myControl = new myControl();

ISerializable serial = myControl as ISerializable;

if (null != serial)

{

bool anotherMoreSuccess = serial.Save();

Console.WriteLine(‘{0}’ Have{1}been successfully saved, with an optimized version., myControl.data, (anotherMoreSuccess ? ” “ : ” not “));

}

Console.ReadLine();

}

}

The solution, with example projects may be downloaded from Interfaces.zip.

I hope this will be useful. 🙂

En el ámbito del desarrollo de software, siempre es bueno eliminar dependencias. En otros términos, bajar el nivel de acoplamiento.

Hay casos en que se logra más directamente y otros en que no es tan simple.

Para estos últimos contamos con un pattern llamado Dependency Injection, Inyección de Dependencia, término por primera vez usado por Martin Fowler. Si te interesa ir a la fuente, acá está su documento sobre Dependency Injection.

En este post voy a intentar explicar que viene a resolver este patrón y sus distintas implementaciones.

Cuando tenemos un objeto que necesita de otro para funcionar correctamente, tenemos definida una dependencia. Esta dependecia puede ser altamente acoplada, tight coupling, o levemente acoplada, loose coupling. Si el acoplamiento es bajo el objeto independiente es fácilmente reemplazable, si, en cambio el acoplamiento es alto, el reemplazo no es fácil y se dificulta el diseño de tests unitarios.

Supongamos que tenemos una clase que define un producto, que necesita un componente, este componente puede provenir de distintos fabricantes, en general cubren las mismas funciones. Los productos son varios y alternativamente pueden valerse del componente de cualquier fabricante.

Si instanciamos uno de los componentes en forma directa necesitamos referenciarlo. Si el mercado nos exige cambiar de componente, tendríamos que eliminar la referencia anterior, crear la nueva, revisar si los métodos, funciones y propiedades son homogéneos, si no lo son, corregir el código donde sea necesario… Si a esto le agregamos que valdría la pena tener una versión con el primer componente y otra con el segundo, la situación empeora. Si hubiera cincuenta componentes alternativos, la situación ya sería inmanejable.

Acá es donde la necesidad del patrón Dependency Injection se hace evidente.

Supongamos que este conjunto de componentes ejecuta básicamente cuatro métodos, que son los que nosotros necesitamos: Initialize, Shutdown, Prepare y DoIt.

Entonces comencemos por escribir una interface que defina estos cuatro métodos:

[VB]

Public Interface ISomeHardware

Sub Initialization()

Sub Shutdown()

Sub Prepare()

Sub DoIt()

End Interface

[C#]

public interface ISomeHardware

{

void Initialization();

void Shutdown();

void Prepare();

void DoIt();

}

Las clases que definan los componentes deben implementar la interface ISomeHardware. En nuestro ejemplo, ComponentA y ComponentB:

[VB]

Public Class ComponentA

Implements ISomeHardware

Public Sub InitializationBegin() Implements ISomeHardware.Initialization

End Sub

Public Sub ShutdownBegin() Implements ISomeHardware.Shutdown

End Sub

Public Sub PrepareBegin() Implements ISomeHardware.Prepare

End Sub

Public Sub DoItBegin() Implements ISomeHardware.DoIt

End Sub

End Class

Public Class ComponentB

Implements ISomeHardware

Public Sub InitializationBegin() Implements ISomeHardware.Initialization

End Sub

Public Sub ShutdownBegin() Implements ISomeHardware.Shutdown

End Sub

Public Sub PrepareBegin() Implements ISomeHardware.Prepare

End Sub

Public Sub DoItBegin() Implements ISomeHardware.DoIt

End Sub

End Class

[C#]

class ComponentA : ISomeHardware

{

public void Initialization() { }

public void Shutdown() { }

public void Prepare() { }

public void DoIt() { }

}

class ComponentB : ISomeHardware

{

public void Initialization() { }

public void Shutdown() { }

public void Prepare() { }

public void DoIt() { }

}

Aclaración: Acá hago una simplificación a efecto didáctico. Las clases que definen ComponentA y ComponentB, en realidad debieran ser wrappers de las dll’s provistas por los fabricantes. Para no complicar inútilmente las dejaré así.

Veremos tres implementaciones del patrón Dependency Injection: por Constructor, por Setter y por Interface.

Por Constructor:

Ahora voy a usar otro patrón llamado Facade o Fachada, la idea es encapsular todos los aspectos complejos de un subsistema de clases en una única y simple interface. En nuestro caso, ProductFacade:

[VB]

Public Class ProductFacade

Private SomeHardware As ISomeHardware

Public Sub New(ByVal pSomeHardware As ISomeHardware)

SomeHardware = pSomeHardware

End Sub

End Class

[C#]

public class ProductFacade

{

private ISomeHardware SomeHardware;

public ProductFacade(ISomeHardware SomeHardware)

{

this.SomeHardware = SomeHardware;

}

}

En esta clase se implementa la Inyección de Dependencia por medio del constructor, que acepta un parámetro de entrada de tipo de interface ISomeHardware. Este punto es determinante. Cualquier clase que implemente la interface ISomeHardware es aceptada como parámetro del constructor de ProductFacade. Este es todo el secreto.

Entonces, para inyectar la dependencia de un componente de un fabricante u otro por Constructor, se hace así:

[VB]

Dim ComponentA As ISomeHardware = New ComponentA

Dim Product01 As ProductFacade = New ProductFacade(ComponentA)

Dim ComponentB As ISomeHardware = New ComponentB

Dim Product02 As ProductFacade = New ProductFacade(ComponentB)

[C#]

ISomeHardware componentA = new ComponentA();

ProductFacade product01 = new ProductFacade(componentA);

ISomeHardware componentB = new ComponentB();

ProductFacade product02 = new ProductFacade(componentB);

Realmente elegante.

Para las siguientes dos implementaciones del patrón, usaremos la misma interface ISomeHardware y la definición de las clases ComponentA y ComponentB.

Las variaciones estarán en la Fachada y en la Inyección de Dependencia.

Por Setter:

En este caso la Inyección de Dependencia se efectiviza a través de una propiedad definida en la Fachada.

[VB]

Public Class ProductFacade

Private mSomeHardware As ISomeHardware

Public Property SomeHardware() As ISomeHardware

Get

Return mSomeHardware

End Get

Set(ByVal value As ISomeHardware)

mSomeHardware = value

End Set

End Property

End Class

[C#]

public class ProductFacade

{

private ISomeHardware SomeHardware;

public ISomeHardware Component

{

get

{

return SomeHardware;

}

set

{

SomeHardware = value;

}

}

}

Para el caso de Setter, la Inyección de Dependencia queda determinada así:

[VB]

Dim ComponentA As ISomeHardware = New ComponentA

Dim Product01 As ProductFacade = New ProductFacade()

Product01.SomeHardware = ComponentA

Dim ComponentB As ISomeHardware = New ComponentB

Dim Product02 As ProductFacade = New ProductFacade()

Product02.SomeHardware = ComponentB

[C#]

ISomeHardware componentA = new ComponentA();

ProductFacade product01 = new ProductFacade();

product01.Component = componentA;

ISomeHardware componentB = new ComponentB();

ProductFacade product02 = new ProductFacade();

product02.Component = componentB;

Por Interface:

Ahora la Inyección de Dependencia está implementada sobre un método que acepta un parámetro de tipo de interface ISomeHardware.

[VB]

Public Class ProductFacade

Private mSomeHardware As ISomeHardware

Public Sub SetComponent(ByVal pSomeHardware As ISomeHardware)

mSomeHardware = pSomeHardware

End Sub

End Class

[C#]

public class ProductFacade

{

private ISomeHardware SomeHardware;

public void SetComponent(ISomeHardware SomeHardware)

{

this.SomeHardware = SomeHardware;

}

}

Cuando la Inyección de Dependencia es por Interface, se invoca de esta forma:

[VB]

Dim ComponentA As ISomeHardware = New ComponentA

Dim Product01 As ProductFacade = New ProductFacade()

Product01.SetComponent(ComponentA)

Dim ComponentB As ISomeHardware = New ComponentB

Dim Product02 As ProductFacade = New ProductFacade()

Product02.SetComponent(ComponentB)

[C#]

ISomeHardware componentA = new ComponentA();

ProductFacade product01 = new ProductFacade();

product01.SetComponent(componentA);

ISomeHardware componentB = new ComponentB();

ProductFacade product02 = new ProductFacade();

product02.SetComponent(componentB);

Las tres implementaciones difieren sutilmente entre si. La diferencia más importante que yo encuentro es que, Por Constructor, nos obliga a inyectar al crear la clase, mientras que las otras modalidades, la difieren para más adelante.

La diferencia entre estas dos últimas está en si se prefiere inyectar la dependencia en el set de una propiedad, Por Setter, o como argumento de un parámetro de entrada a un método o función, Por Interface. Cuestión de gusto sintáctico.

Espero que les sea útil. 🙂

En este post voy a escribir sobre métodos genéricos. La idea es presentar un método que acepte dos parámetros de tipo genérico.

Para quien no maneje el concepto de Generics recomiendo antes leer este post.

Vamos a usar un proyecto de tipo Consola con Visual Studio .NET, y la misma clase Libro que usé en el post anterior.

Primero, referenciamos lo siguiente:

C#

using System;

using System.Collections.Generic;

VB.NET

Imports System

Imports System.Collections.Generic

Ahora si, la clase Libro:

C#

public class Libro

{

public string sTitulo, sAutor;

public Libro(string Titulo, string Autor)

{

sTitulo = Titulo;

sAutor = Autor;

}

public override string ToString()

{

return string.Format(“{0} escribió {1}.”, sAutor, sTitulo);

}

}

VB.NET

Public Class Libro

Dim sTitulo, sAutor As String

Public Sub New(ByVal Titulo As String, ByVal Autor As String)

MyBase.New()

sTitulo = Titulo

sAutor = Autor

End Sub

Public Overrides Function ToString() As String

Return String.Format(“{0} escribió {1}.”, sAutor, sTitulo)

End Function

End Class

En el módulo principal codificamos nuestro método MostrarPorConsola que podrá recibir dos parámetros de cualquier tipo:

C#

static void MostrarPorConsola<T>(ref T a, ref T b)

{

Console.WriteLine(“Primer  argumento del método MostrarPorConsola(), {0}, de tipo {1}.”, a, typeof(T));

Console.WriteLine(“Segundo argumento del método MostrarPorConsola(), {0}, de tipo {1}.”, b, typeof(T));

}

VB:NET

Private Sub MostrarPorConsola(Of T)(ByRef a As T, ByRef b As T)

Console.WriteLine(“Primer  argumento del método MostrarPorConsola(), {0}, de tipo {1}.”, a, GetType(T))

Console.WriteLine(“Segundo argumento del método MostrarPorConsola(), {0}, de tipo {1}.”, b, GetType(T))

End Sub

El método imprime una línea con el primer argumento y otra más con el segundo, sin interesar de que tipo son.

En la rutina principal consumimos al método genérico, primero declaro dos enteros, les asigno un valor y se los paso como parámetros al método MostrarPorConsola, luego declaro dos objetos de tipo Libro, los hidrato y se los paso como parámetros al mismo método.

Parece mentira… pero funciona 🙂

Este post es continuación de este anterior sobre Delegates. Si ya conocés el tema no te va a hacer falta empezar por él.

En .NET tenemos la posibilidad de publicar un evento, al cual uno o más objetos pueden suscribirse.

Cuando se produce el evento, el aplicativo informa a los objetos suscriptos, que en el entorno del evento ejecutarán el código que contengan en la definición de su clase.

Al producirse el evento se invoca un método definido por medio de un delegado

Este Delegate debe recibir dos parámetros de entrada, el primero de tipo Object que recibe el objeto que produce el evento, el segundo es algún objeto que derive de la clase EventArgs.

Vamos a ver un ejemplo con el que jamás podremos a llamar la atención de nadie que nos interese. 🙂

Desde este link pueden descargarlo.

Vamos a tener tres formularios, el primero de ellos tiene un TrackBar que cuando se modifica los otros dos formularios se “enteran” y muestran la modificación a través de un textBox.

El primer punto interesante es que no tengo que agregar nada de código en los formularios que se “enteran” del evento. En el ejemplo que les dejo, en VB.NET y C#, podemos ver que en los Form2 y Form3 sólo hay estructura para verse como formularios y para soportar un textBox.

Empiezo por la clase TrackBarChangeEventsArgs que encapsula el valor que toma el TrackBar cuando se modifica su estado.

[VB]

Imports System

 

”’ <summary>

”’ Encapsula el argumento del evento, en este caso es un entero

”’ que representa al valor del TrackBar.

”’ </summary>

”’ <remarks>La clase hereda de EventArgs.</remarks>

Class TrackBarChangeEventsArgs

    Inherits EventArgs

 

    Private mChange As Integer

 

    ”’ <summary>

    ”’ Constructor

    ”’ </summary>

    ”’ <param name=”pChange”>Valor del TrackBar.</param>

    ”’ <remarks></remarks>

    Public Sub New(ByVal pChange As Integer)

        MyBase.New()

        Me.mChange = pChange

    End Sub

 

    ”’ <summary>

    ”’ Publica el valor del argumento del evento, en este caso

    ”’ el valor del TrackBar.

    ”’ </summary>

    ”’ <value></value>

    ”’ <returns>Valor del TrackBar</returns>

    ”’ <remarks></remarks>

    Public ReadOnly Property Change() As Integer

        Get

            Return mChange

        End Get

    End Property

End Class

 

 

[C#]

using System;

 

/// <summary>

/// Encapsula el argumento del evento, en este caso es un entero

/// que representa al valor del TrackBar.

/// </summary>

/// <remarks>La clase hereda de EventArgs.</remarks>

class TrackBarChangeEventsArgs : EventArgs

{

    private int mChange;

 

    /// <summary>

    /// Constructor

    /// </summary>

    /// <param name=”pChange”>Valor del TrackBar.</param>

    /// <remarks></remarks>

    public TrackBarChangeEventsArgs(int pChange)

    {

        this.mChange = pChange;

    }

 

    /// <summary>

    /// Publica el valor del argumento del evento, en este caso

    /// el valor del TrackBar.

    /// </summary>

    /// <value></value>

    /// <returns>Valor del TrackBar</returns>

    /// <remarks></remarks>

    public int Change

    {

        get

        {

            return mChange;

        }

    }

}

 

Podemos ver que la clase deriva de EventArgs, tiene un constructor que recibe como parámetro el valor del TrackBar y publica al mismo mediante una propiedad Read Only.

Ahora veamos la clase encargada de publicar el evento, en el ejemplo es TrackBarAdministrador, en ella es donde se declara el Delegate de nombre TrackBarChangeEventHandler, que, como mencioné antes, recibe dos parámetros uno de tipo Object que contiene al objeto que disparó el evento y otro que deriva de EventArgs, esta ves es TrackBarChangeEventArgs.

A continuación se declara el evento OnTrackBarChangeHandler del tipo Delegate TrackBarChangeEventHandler.

La clase tiene un único método llamado ChangeTrackBar que acepta un sólo parámetro de tipo entero que es el valor del TrackBar. En este método se declara una variable llamada e del tipo de la clase TrackBarChangeEventsArgs (la que encapsula y publica el valor del TrackBar) y se le pasa el parámetro que se recibió, el entero que representa el valor del TrackBar. Ahora se dispara el evento OnTrackBarChangeHandler pasándole como parámetros el propio objeto (que es una instancia de la clase TrackBarAdministrador) y con esto queda publicado el evento.

Veamos la clase:

[VB]

Imports System

 

”’ <summary>

”’ Administra el evento de cambio de valor del TrackBar.

”’ </summary>

”’ <remarks></remarks>

Class TrackBarAdministrador

    ”’ <summary>

    ”’ Declaro un Delegate de nombre TrackBarChangeEventHandler. A

    ”’ Continuación declaro un evento del tipo del Delegate, que

    ”’ será el evento a propagar.

    ”’ </summary>

    ”’ <param name=”source”>Parámetro de entrada de tipo Object</param>

    ”’ <param name=”e”>Parámetro de entrada de tipo TrackBarChangeEventsArgs</param>

    ”’ <remarks>Esta es la clase que administra el evento a producirse al

    ”’ cambiar el valor del TrackBar</remarks>

    Public Delegate Sub TrackBarChangeEventHandler(ByVal source As Object, ByVal e As TrackBarChangeEventsArgs)

    Public Event OnTrackBarChangeHandler As TrackBarChangeEventHandler

 

    ”’ <summary>

    ”’ Método que recibe el valor a propagar.

    ”’ </summary>

    ”’ <param name=”pChange”>Valor del TrackBar a propagar.</param>

    ”’ <remarks></remarks>

    Public Sub ChangeTrackBar(ByVal pChange As Integer)

        Dim e As TrackBarChangeEventsArgs = New TrackBarChangeEventsArgs(pChange)

        RaiseEvent OnTrackBarChangeHandler(Me, e)

    End Sub

End Class

[C#]

using System;

 

/// <summary>

/// Administra el evento de cambio de valor del TrackBar.

/// </summary>

/// <remarks></remarks>

class TrackBarAdministrador

{

    public event TrackBarChangeEventHandler OnTrackBarChangeHandler;

 

    /// <summary>

    /// Método que recibe el valor a propagar.

    /// </summary>

    /// <param name=”pChange”>Valor del TrackBar a propagar.</param>

    /// <remarks></remarks>

    public void ChangeTrackBar(int pChange)

    {

        TrackBarChangeEventsArgs e = new TrackBarChangeEventsArgs(pChange);

        OnTrackBarChangeHandler(this, e);

    }

 

    /// <summary>

    /// Declaro un Delegate de nombre TrackBarChangeEventHandler. A

    /// Continuación declaro un evento del tipo del Delegate, que

    /// será el evento a propagar.

    /// </summary>

    /// <param name=”source”>Parámetro de entrada de tipo Object</param>

    /// <param name=”e”>Parámetro de entrada de tipo TrackBarChangeEventsArgs</param>

    /// <remarks>Esta es la clase que administra el evento a producirse al

    /// cambiar el valor del TrackBar</remarks>

    public delegate void TrackBarChangeEventHandler(object source, TrackBarChangeEventsArgs e);

}

 

Nos queda por ver la clase engargada de notificar la ocurrencia del evento que en este caso se llama TrackBarObservador.

Si bien la clase tiene este nombre, esto no significa que estemos aplicando el patrón Observer, para quien le interese este patrón acá hay un artículo descriptivo.

Esta clase tiene un constructor que acepta como parámetro un objeto del tipo de la clase TrackBarAdministrador, lo guarda en una variable local y vincula al evento OnTrackBarChangeHandler declarado en la clase TrackBarAdministrador al método OnTrackBarChange definido más adelante en esta misma clase. Este método es donde se realizan las suscripciones de los formularios Form2 y Form3 que serán notificados del cambio en el TrackBar.

[VB]

Imports System

 

”’ <summary>

”’ Informa a los formularios sobre el evento que administra TrackBarAdministrador.

”’ </summary>

”’ <remarks></remarks>

Class TrackBarObservador

    ”’ <summary>

    ”’ Variable local del tipo de la clase que administra el evento

    ”’ a producirse al cambiar el vaor del TrackBar.

    ”’ </summary>

    ”’ <remarks></remarks>

    Private mTrackBarAdministrador As TrackBarAdministrador

 

    ”’ <summary>

    ”’ Constructor

    ”’ </summary>

    ”’ <param name=”pTrackBarAdministrador”>Recibe una instancia de la clase

    ”’ que administra el evento a producirse al cambiar el valor del

    ”’ TrackBar</param>

    ”’ <remarks>Se agrega al método local OnTrackBarChange como manipulador

    ”’ del evento de tipo Delegate declarado en la clase TrackBarAdministrador.</remarks>

    Public Sub New(ByVal pTrackBarAdministrador As TrackBarAdministrador)

        ‘MyBase.New()

        Me.mTrackBarAdministrador = pTrackBarAdministrador

        AddHandler mTrackBarAdministrador.OnTrackBarChangeHandler, AddressOf Me.OnTrackBarChange

    End Sub

 

    ”’ <summary>

    ”’ Método que manipula al evento a producirse al variar el valor del TrackBar.

    ”’ </summary>

    ”’ <param name=”source”>Parámetro de entrada de tipo Object</param>

    ”’ <param name=”e”>Parámetro de entrada de tipo TrackBarChangeEventsArgs</param>

    ”’ <remarks>Es importante destacar que los parámetros de este método deben ser

    ”’ idénticos a los de la firma del evento de tipo Delegate declarado en la clase

    ”’ TrackBarAdministrador.</remarks>

    Private Sub OnTrackBarChange(ByVal source As Object, ByVal e As TrackBarChangeEventsArgs)

        Form2.txtValor.Text = e.Change

        Form3.txtValor.Text = e.Change

    End Sub

End Class

 

[C#]

using System;

 

/// <summary>

/// Informa a los formularios sobre el evento que administra TrackBarAdministrador.

/// </summary>

/// <remarks></remarks>

class TrackBarObservador

{

    Form2 miForm2 = new Form2();

    Form3 miForm3 = new Form3();

 

    /// <summary>

    /// Variable local del tipo de la clase que administra el evento

    /// a producirse al cambiar el vaor del TrackBar.

    /// </summary>

    /// <remarks></remarks>

    private TrackBarAdministrador mTrackBarAdministrador;

 

    /// <summary>

    /// Constructor

    /// </summary>

    /// <param name=”pTrackBarAdministrador”>Recibe una instancia de la clase

    /// que administra el evento a producirse al cambiar el valor del

    /// TrackBar</param>

    /// <remarks>Se agrega al método local OnTrackBarChange como manipulador

    /// del evento de tipo Delegate declarado en la clase TrackBarAdministrador.</remarks>

    public TrackBarObservador(TrackBarAdministrador pTrackBarAdministrador)

    {

        this.miForm2.Show();

        this.miForm3.Show();

        this.mTrackBarAdministrador = pTrackBarAdministrador;

        mTrackBarAdministrador.OnTrackBarChangeHandler += new TrackBarAdministrador.TrackBarChangeEventHandler(this.OnTrackBarChange);

    }

 

    /// <summary>

    /// Método que manipula al evento a producirse al variar el valor del TrackBar.

    /// </summary>

    /// <param name=”source”>Parámetro de entrada de tipo Object</param>

    /// <param name=”e”>Parámetro de entrada de tipo TrackBarChangeEventsArgs</param>

    /// <remarks>Es importante destacar que los parámetros de este método deben ser

    /// idénticos a los de la firma del evento de tipo Delegate declarado en la clase

    /// TrackBarAdministrador.</remarks>

    private void OnTrackBarChange(object source, TrackBarChangeEventsArgs e)

    {

        this.miForm2.txtValor.Text = e.Change.ToString();

        this.miForm3.txtValor.Text = e.Change.ToString();

    }

}

Pasamos ahora al Form1 que es el que controla la aplicación. Este formulario en su componente visual contiene un TrackBar. En él se declaran una variable local de tipo de la clase TrackBarAdministrador, otra más del tipo de la clase TrackBarObservador y se le pasa la variable de tipo TrackBarAdministrador, recién declarada, como parámetro.

En el evento Scroll del TrackBar, es el que se dispara al cambiar manualmente su valor, ejecutamos el método ChangeTrackBar declarado en la clase TrackBarAdministrador que es el encargado de disparar el evento OnTrackBarChangeHandler y se cierra el círculo.

[VB]

”’ <summary>

”’ Desde este formulario se controlan los valores de Título y

”’ TextBox de los otros dos.

”’ </summary>

”’ <remarks></remarks>

Public Class Form1

    ”’ <summary>

    ”’ Declaro una variable local del tipo TrackBarAdministrador. Luego otra del

    ”’ tipo TrackBarObservador, a la que se le pasa TrackBarAdministrador como

    ”’ parámetro de entrada.

    ”’ </summary>

    ”’ <remarks></remarks>

    Private mTrackBarAdministrador As TrackBarAdministrador = New TrackBarAdministrador

    Private mTrackBarObservador As TrackBarObservador = New TrackBarObservador(mTrackBarAdministrador)

 

    ”’ <summary>

    ”’ Muestro los formularios que se recibirán al evento desde la clase

    ”’ TrackBarObservador.

    ”’ </summary>

    ”’ <param name=”sender”></param>

    ”’ <param name=”e”></param>

    ”’ <remarks></remarks>

    Private Sub Form1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load

        Form2.Show()

        Form3.Show()

    End Sub

 

    ”’ <summary>

    ”’ Al modificarse el valor del TrackBar se dispara el evento ChangeTrackBar

    ”’ declarado en TrackBarAdministrador.

    ”’ </summary>

    ”’ <param name=”sender”></param>

    ”’ <param name=”e”></param>

    ”’ <remarks></remarks>

    Private Sub TrackBar_Scroll(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles TrackBar.Scroll

        mTrackBarAdministrador.ChangeTrackBar(sender.Value)

    End Sub

End Class

[C#]

using System;

using System.Windows.Forms;

 

/// <summary>

/// Desde este formulario se controlan los valores de Título y

/// TextBox de los otros dos.

/// </summary>

public partial class Form1 : Form

{

    public Form1()

    {

        InitializeComponent();

    }

 

    /// <summary>

    /// Declaro una variable local del tipo TrackBarAdministrador. Luego otra del

    /// tipo TrackBarObservador, a la que se le pasa TrackBarAdministrador como

    /// parámetro de entrada.

    /// </summary>

    static TrackBarAdministrador mTrackBarAdministrador = new TrackBarAdministrador();

    TrackBarObservador mTrackBarObservador = new TrackBarObservador(mTrackBarAdministrador);

 

    /// <summary>

    /// Muestro los formularios que se recibirán al evento desde la clase

    /// TrackBarObservador.

    /// </summary>

    /// <param name=”sender”></param>

    /// <param name=”e”></param>

    /// <remarks></remarks>

    private void Form1_Load(object sender, System.EventArgs e)

    {

        Application.Run(new Form2());

        Application.Run(new Form3());

    }

 

    /// <summary>

    /// Al modificarse el valor del TrackBar se dispara el evento ChangeTrackBar

    /// declarado en TrackBarAdministrador.

    /// </summary>

    /// <param name=”sender”></param>

    /// <param name=”e”></param>

    /// <remarks></remarks>

    private void trackBar_Scroll(object sender, System.EventArgs e)

    {

        mTrackBarAdministrador.ChangeTrackBar(((System.Windows.Forms.TrackBar)(sender)).Value);

    }

}

No publico el código de los otros dos formularios porque no contienen más código que el necesario para ser formularios y contener un textBox de nombre txtValor, pueden verificarlo en los ejemplos que les dejo acá para bajar y probar.

Con la idea de haber sido útil, me despido hasta la próxima. 🙂

Hay situaciones en programación que no son de resolución trivial.

Supongamos que tenemos instanciado un objeto servidor y necesitamos conocer algún cambio de estado en el mismo.

Podríamos solucionarlo con un Timer, pero como solución es excesivamente costosa e impráctica. Hay quien sencillamente programa una función en el objeto servidor que avisa al cliente, un horror, desde el punto de vista de la orientación a objetos, impide la reutilización de código, etc.

Para este tipo de situaciones existen salidas más elegantes y efectivas que es lo que vamos a ver en esta nota.

Los delegados son algo similar a los punteros a funciones en C++, pero como corren sobre el Framework de .NET se trata de código administrado (code managed) y de tipo seguro.

Se usan para implementar métodos de devolución de llamada, callbacks, que son fundamentales para lograr:programar procesamiento asíncrono o para insertar código de cliente, entre las instancias que produce el servidor, para no usar timers donde no sea necesario.

Los métodos de devolución de llamada se usan en procesamiento asíncrono porque se desconoce el tiempo que va a tardar en ejecutarse el método que se invoca y que potencialmente podría ser largo.

En este caso vamos a ver como se usan delegados para insertar código de cliente, entre las devoluciones de llamada que produce el servidor.

Para entender esto, vamos a pensar en una aplicación que toma mediciones que pueden tardar en completarse, para el ejemplo no nos importa la medición, por eso la vamos a implementar como una medición simulada en una clase de nombre Measures. Tendremos además otra clase, Manager, que administra las mediciones y una aplicación de consola de nombre App.

Veamos primero la clase Measure: 

[C#]

using System; class Measure{

     /// <summary>

     /// Variable protegida que encapsula el valor de la propiedad Name.

    /// </summary>

     /// <remarks></remarks>

     protected string Name;

     /// <summary>

     /// Constructor de la clase que implementa una Medición simulada.

     /// </summary>

     /// <param name=”name”>Nombre concreto de la Medición.</param>

     /// <remarks>Es una forma de diferenciar las distintas instacias

    /// que se produzcan de esta clase.</remarks>

     public Measure(string name)

    {

        this.name = name;

    }

    /// <summary>

    /// Propiedad Name.

    /// </summary>

    /// <value></value>

    /// <returns>Nombre (Name) de la instancia.</returns>

    /// <remarks>Las últimas dos lineas del get simulan una demora en la

    /// toma de la medición, pongo un beep para que sea más perceptible la

    /// demora entre callbacks. Esto para poder apreciar mejor que se está

    /// haciedo un callback por cada medición, de otra forma el tipo de output de

    /// consola no da idea de cómo se ejecuta el código.</remarks>

    public string name

    {

        get

        {

            for (int i = 0; i <= 100000000; i++) { }            System.Media.SystemSounds.Beep.Play();            return this.Name;        }

        set

        {

            this.Name = value;

        }

    }

} 

[VB]

Imports System 

Public Class Measure

    ”’ <summary>

    ”’ Variable protegida que encapsula el valor de la propiedad Name.

    ”’ </summary>

    ”’ <remarks></remarks>

    Protected strName As String

    ”’ <summary>

    ”’ Constructor de la clase que implementa una Medición simulada.

    ”’ </summary>

    ”’ <param name=”name”>Nombre concreto de la Medición.</param>

    ”’ <remarks>Es una forma de diferenciar las distintas instacias

    ”’ que se produzcan de esta clase.</remarks>

    Public Sub New(ByVal name As String)

        MyBase.New()

        Me.name = name

    End Sub

    ”’ <summary>

    ”’ Propiedad Name.

    ”’ </summary>

    ”’ <value></value>

    ”’ <returns>Nombre (Name) de la instancia.</returns>

    ”’ <remarks>Las últimas tres lineas del Get simulan una demora en la

    ”’ toma de la medición, pongo un beep para que sea más perceptible la

    ”’ demora entre callbacks. Esto para poder apreciar mejor que se está

    ”’ haciedo un callback por cada medición, de otra forma el tipo de output de

    ”’ consola no da idea de cómo se ejecuta el código.</remarks>

    Public Property name() As String

        Get

            Dim i As Int64            For i = 0 To 100000000 : Next            Beep()            Return strName

        End Get

        Set(ByVal value As String)

            strName = value

        End Set

    End Property

End Class 

 

Seguimos ahora con la clase Manager: 

[C#]

using System; 

class Manager{

    /// <summary>

    /// Es una constante donde se define la cantidad de

    /// mediciones simuladas que se harán.

    /// </summary>

    /// <remarks></remarks>

    int kMeasure = 4;

    /// <summary>

    /// Arreglo de Measures que soporta las mediciones.

    /// </summary>

    /// <remarks></remarks>

    static Measure[] Measures;

    /// <summary>

    /// Definición de la función Delegada

    /// </summary>

    /// <param name=”pMeasure”>Recibe un objeto Measure como entrada</param>

    /// <remarks>Esta es la función sobre la que se implementa el método

    /// de devolución de llamada (callback) al nombre de esta función se

    /// lo postfija con Callback por convención con la idea de facilitar

    /// la lectura.</remarks>

    public delegate void EnumMeasuresCallback(Measure measure);

    /// <summary>

    /// Agrega mediciones simuladas.

    /// </summary>

    /// <remarks>Se agregan tantas como hayan definido en kMeasure.</remarks>

    public void AddMeasures()

    {

        Measures = new Measure[kMeasure];

        for (System.Int64 i = 0; i < kMeasure; i++)

        {

            Measures[i] = new Measure(“Measure “ + (i + 1));

        }

    }

    /// <summary>

    /// Enumera mediciones, es la función que se invocará desde la aplicación.

    /// </summary>

    /// <param name=”callback”>Función delegada.</param>

    /// <remarks>Aceptando una función delegada como parámetro de entrada

    /// es la forma en que en que queda establecido efectivamente el callback.</remarks>

    public static void EnumMeasures(EnumMeasuresCallback callback)

    {

        foreach (Measure measure in Measures)

        {

            callback(measure);

        }

    }

}  

[VB]

Imports System 

Public Class Manager

    ”’ <summary>

    ”’ Es una constante donde se define la cantidad de

    ”’ mediciones simuladas que se harán.

    ”’ </summary>

    ”’ <remarks></remarks>

    Private Const kMeasure As Integer = 4

    ”’ <summary>

    ”’ Arreglo de Measures que soporta las mediciones.

    ”’ </summary>

    ”’ <remarks></remarks>

    Private Shared Measures(kMeasure) As Measure

    ”’ <summary>

    ”’ Definición de la función Delegada

    ”’ </summary>

    ”’ <param name=”pMeasure”>Recibe un objeto Measure como entrada</param>

    ”’ <remarks>Esta es la función sobre la que se implementa el método

    ”’ de devolución de llamada (callback) al nombre de esta función se

    ”’ lo postfija con Callback por convención con la idea de facilitar

    ”’ la lectura.</remarks>

    Public Delegate Sub EnumMeasuresCallback(ByVal pMeasure As Measure)

    ”’ <summary>

    ”’ Agrega mediciones simuladas.

    ”’ </summary>

    ”’ <remarks>Se agregan tantas como hayan definido en kMeasure.</remarks>

    Public Sub AddMeasures()

        Dim i As Integer

        For i = 0 To kMeasure

            Measures(i) = New Measure((“Measure “ + CStr(i + 1)))

        Next i

    End Sub

    ”’ <summary>

    ”’ Enumera mediciones, es la función que se invocará desde la aplicación.

    ”’ </summary>

    ”’ <param name=”callback”>Función delegada.</param>

    ”’ <remarks>Aceptando una función delegada como parámetro de entrada

    ”’ es la forma en que en que queda establecido efectivamente el callback.</remarks>

    Public Shared Sub EnumMeasures(ByVal callback As EnumMeasuresCallback)

        For Each mMeasure As Measure In Measures

            callback(mMeasure)

        Next

    End Sub

End Class 

 

Las lineas más destacables de Manager son  

[C#]

public delegate void EnumMeasuresCallback(Measure measure);

[VB]

Public Delegate Sub EnumMeasuresCallback(ByVal pMeasure As Measure)

Esta es la definición de la función sobre la que se implementará el callback 

[C#]

    public static void EnumMeasures(EnumMeasuresCallback callback)

    {

        foreach (Measure measure in Measures)

        {

            callback(measure);

        }

    }

[VB]

    Public Shared Sub EnumMeasures(ByVal callback As EnumMeasuresCallback)

        For Each mMeasure As Measure In Measures

            callback(mMeasure)

        Next

    End Sub

Esta es la función que se invocará desde la aplicación (que todavía no vimos), su característica más saliente es que recibe una función delegada como parámetro de entrada. 

Por último la aplicación de consola: 

[C#]

using System;

/// <summary>

/// Esta es la aplicación desde dónde compruebo el funcionamiento de los callbacks.

/// </summary>

/// <remarks>Esta primera línea de código

/// Public Shared miCallback As Manager.EnumMeasuresCallback = New Manager.EnumMeasuresCallback(AddressOf MeasuresCallback)

/// En esta definición es dónde efectivamente relaciono la función delegada

/// con una función de la aplicación. En otras palabras, delego la función

/// EnumMeasuresCallback (definida en Manager) en MeasuresCallback (definida

/// localmente). En esta misma linea estoy definiendo la varibal miCallback,

/// de tipo Delegate, implícito en Manager.EnumMeasuresCallback.</remarks>

class App{

    public static Manager.EnumMeasuresCallback miCallback = new Manager.EnumMeasuresCallback(MeasuresCallback);

    /// <summary>

    /// Acá se inserta el código que se quiere ejecutar por cada callback.

    /// </summary>

    /// <param name=”pMeasure”></param>

    /// <remarks></remarks>

    public static void MeasuresCallback(Measure measure)

    {

        Console.WriteLine(“Callback “ + measure.name);

    }

    /// <summary>

    /// Rutina principal de la aplicación

    /// </summary>

    /// <remarks>Con mgr.AddMeasures(), agrego las mediciones simuladas.

    /// En la invocación

    /// Manager.EnumMeasures(miCallback)

    /// está la llamada a la función que implementa el callback.

    /// En la clase Manager podrá verse que es la función

    /// que recibe un Delegate como parámetro de entrada.

    /// Es así que le paso el delegado que definí más arriba

    /// con nombre miCallback.

    /// </remarks>

    public static void Main()

    {

        Manager mgr = new Manager();

        Console.WriteLine(“Agrego mediciones”);

        mgr.AddMeasures();

        Console.WriteLine(“Entra”);

        Manager.EnumMeasures(miCallback);

        Console.WriteLine(“Sale”);

        Console.ReadLine();

    }

} 

[VB]

Imports System 

”’ <summary>

”’ Esta es la aplicación desde dónde compruebo el funcionamiento de los callbacks.

”’ </summary>

”’ <remarks>Esta primera línea de código

”’ Public Shared miCallback As Manager.EnumMeasuresCallback = New Manager.EnumMeasuresCallback(AddressOf MeasuresCallback)

”’ En esta definición es dónde efectivamente relaciono la función delegada

”’ con una función de la aplicación. En otras palabras, delego la función

”’ EnumMeasuresCallback (definida en Manager) en MeasuresCallback (definida

”’ localmente). En esta misma linea estoy definiendo la varibal miCallback,

”’ de tipo Delegate, implícito en Manager.EnumMeasuresCallback.</remarks>

Class App

    Public Shared miCallback As Manager.EnumMeasuresCallback = New Manager.EnumMeasuresCallback(AddressOf MeasuresCallback)

    ”’ <summary>

    ”’ Acá se inserta el código que se quiere ejecutar por cada callback.

    ”’ </summary>

    ”’ <param name=”pMeasure”></param>

    ”’ <remarks></remarks>

    Public Shared Sub MeasuresCallback(ByVal pMeasure As Measure)

        Console.WriteLine((“Callback “ + pMeasure.name))

    End Sub

    ”’ <summary>

    ”’ Rutina principal de la aplicación

    ”’ </summary>

    ”’ <remarks>Con mgr.AddMeasures(), agrego las mediciones simuladas.

    ”’ En la invocación

    ”’ Manager.EnumMeasures(miCallback)

    ”’ está la llamada a la función que implementa el callback.

    ”’ En la clase Manager podrá verse que es la función

    ”’ que recibe un Delegate como parámetro de entrada.

    ”’ Es así que le paso el delegado que definí más arriba

    ”’ con nombre miCallback.

    ”’ </remarks>

    Public Shared Sub Main()

        Dim mgr As Manager = New Manager

        Console.WriteLine(“Agrego Mediciones”)

        mgr.AddMeasures()

        Console.WriteLine(“Entra”)

        Manager.EnumMeasures(miCallback)

        Console.WriteLine(“Sale”)

        Console.ReadLine()

    End Sub

End Class 

 

Lo fundamental en la aplicación son las siguientes líneas de código: 

[C#]

public static Manager.EnumMeasuresCallback miCallback = new Manager.EnumMeasuresCallback(MeasuresCallback);

[VB]

Public Shared miCallback As Manager.EnumMeasuresCallback = New Manager.EnumMeasuresCallback(AddressOf MeasuresCallback)

Acá se declara el delegado (miCallback) que se pasará como parámetro de entrada a la función EnumMeasures que implementa el callback en Manager. Es importante notar que la función de devolución de llamada recibe como parámetro de entrada la dirección de la función delegada 

[C#]

Manager.EnumMeasures(miCallback);

[VB]

Manager.EnumMeasures(miCallback)

En estas líneas estamos invocando a la función que implementa el callback, para eso se le pasa cómo parámetro el delegado definico al comienzo.  

[C#]

    public static void MeasuresCallback(Measure measure)

    {

        Console.WriteLine(“Callback “ + measure.name);

    }

[VB]

    Public Shared Sub MeasuresCallback(ByVal pMeasure As Measure)

        Console.WriteLine((“Callback “ + pMeasure.name))

    End Sub

Esta es la función delegada. En otras palabras en ella se delega el Delegate, como se define en la declaración de miCallback. 

Este es sólo un ejemplo que usa Delegates, hay mucho más sobre este tema.

La solución con los proyectos de ejemplo se pueden descargar de Delegates.zip.

Para quien quiera profundizar es recomendable cualquier libro, en especial el libro de Tom Archer que conocí gracias a la desinteresada recomendación de Daniel Calvin. 

ISBN: 84-481-3246-7

Autor: Tom Archer (http://blogs.msdn.com/tomarcher/)

Título: C# a fondo (http://www.cuspide.com/isbn/8448132467)
Editorial: Mc Graw Hill. 

 

Les mando un saludo. 🙂

Implementar una interface es establecer un contrato entre dos bloques de código, donde el bloque que implementa la interface se compromete a implementar concretamente los métodos que la interface implementada define. 

En principio esto a veces suena raro. La pregunta que surge es ¿no me estaré complicando la vida?… depende… 

Supongamos que en el marco de un proceso tenemos un conjunto de objetos heterogéneos que desconocemos. Algunos tienen un método de serialización de nombre Save, si el método existe, es el encargado de persistit al objeto. Si no existe el método Save, el objeto se persiste en base de datos por medio de otro método.

La pregunta es ¿cómo preguntar, en tiempo de ejecución, si un objeto implementa un método de un determinado nombre?Lo que sigue intenta responder esto. Para desarrollar este ejemplo, hay que abrir Visual Studio y crear un proyecto de Windows de Consola en Visual Basic o C#.

Ahora creamos la interface ISerializable, que contiene la función Save que devuelve un boolean: 

[VB]

Public Interface ISerializable   

    Function Save() As Boolean

End Interface 

[C#]

using System; 

interface ISerializable

    {

        bool Save();

    }

Por convención a los nombres de las interfaces se les prefija una “I” para una mejor identificación. 

Luego vamos a crear una clase, de nombre Controlcito, con una única propiedad llamada Datos de tipo string: 

[VB]

Public Class Controlcito

    Private mDatos As String

    Public Property Datos() As String

        Get

            Return mDatos

        End Get

        Set(ByVal value As String)

            mDatos = value

        End Set

    End Property

End Class 

[C#]

using System;

     public class Controlcito

    {

        protected string Data;

        public string data

        {

            get

            {

                 return this.Data;

            }

            set

            {

                this.Data = value;

            }

        }

    }

 Defino ahora un control, con nombre miControl, que herede de Controlcito e implemente la interface ISerializable 

[VB]

Public Class miControl

    Inherits Controlcito

    Implements ISerializable

     Public Sub New()

        Datos = “Estos son los datos de prueba…”

     End Sub

     Public Function Save() As Boolean

         Implements ISerializable.Save

        Console.WriteLine(“Grabando…{0}”, Datos)

        Return True

    End Function

End Class 

 

[C#]

using System;

class miControl : Controlcito, IValidate, ISerializable 

    {

        public miControl()

        {

            data = “Mis datos de prueba.”;

        }

         public bool Save()

        {

            Console.WriteLine(“Grabando…{0}”, data);

            return true;

        }

    }

De esta forma queda implementado, efectivamente, el método Save de la interface ISerializable. Verán que al tipear la linea de código referida a la implementación de la interface, cuando se hace click en Enter, Visual Studio escribe el encabezado de la función que define la interface.

Ya sabemos cómo implementar una Interface.

Ahora el problema es saber, programáticamente, si una clase implementa una Interface. Para el ejemplo que estamos viendo, en términos concretos, es saber si la clase tiene implementado un método Save, en otras palabras, si la clase implementa algún método de serialización.

Entonces vamos a escribir la aplicación que se lanzará en consola, la llamamos App 

[VB]

Module App

    Sub Main()

        Console.WriteLine(“Versión Visual Basic”)

        Dim miControl As New miControl

        Dim ser As ISerializable = DirectCast(miControl, ISerializable)

        Dim exito As Boolean = ser.Save

        Console.WriteLine(“La validación de ‘{0}’ {1} fue correcta”, miControl.Datos, IIf(exito, “”, “no”))

    End Sub

    Console.ReadLine()

End Module 

 

[C#]

class App

    {

        public static void Main()

        {

            Console.WriteLine(“Versión C#”);

            miControl miControl = new miControl();

            ISerializable ser = (ISerializable)miControl;

            bool exito = ser.Save();

            Console.WriteLine(“La validación de ‘{0}’ {1} fue correcta”, miControl.data, (true == exito ? “” : “no”));

        }

        Console.ReadLine();

    }

Esto parece funcionar, pero si la interface no está implementada DirectCast(miControl, ISerializable), en VB, o (ISerializable)miControl, en C#, ambos, en ese caso dan error.

La forma correcta de preguntar es TypeOf (miControl) Is ISerializable, en VB, o miControl Is ISerializable, en C#. Veamos:

[VB]

Module App

    Sub Main()

        Console.WriteLine(“Versión Visual Basic”)

        Dim miControl As New miControl

        If TypeOf (miControl) Is ISerializable Then

            Dim ser As ISerializable = DirectCast(miControl, ISerializable)

            Dim otroExito As Boolean = ser.Save

            Console.WriteLine(“Los Datos de ‘{0}’ {1} se han guardado satisfactoriamente”, miControl.Datos, IIf(otroExito, “”, “no”))

        End If

        Console.ReadLine()

    End Sub

End Module 

[C#]

class App

    {

        public static void Main()

        {

            Console.WriteLine(“Versión C#”);

            miControl miControl = new miControl();

            if (miControl is ISerializable)

            {

                ISerializable ser = (ISerializable)miControl;

                bool otroExito = ser.Save();

                Console.WriteLine(“Los Datos de ‘{0}’ {1} se han guardado satisfactoriamente”, miControl.data, (true == otroExito ? “” : “no”));

            }

            Console.ReadLine();

        }

    }

Esto funciona correctamente en ambos lenguajes. Pero existe una forma optimizada, en términos de código MSIL.

En VB se usa TryCast que evalúa si la interface está implementada, si no lo está, no devuelve error sino Nothing. En C# esto es análogo con el operador as. 

[VB]

Module App

    Sub Main()

        Console.WriteLine(“Versión Visual Basic”)

        Dim miControl As New miControl

        Dim serial As ISerializable = TryCast(miControl, ISerializable)

        If Not serial Is Nothing Then

            Dim otroExitoMas As Boolean = serial.Save

            Console.WriteLine(“Los Datos de ‘{0}’ {1} se han guardado satisfactoriamente, con una versión optimizada”, miControl.Datos, IIf(otroExitoMas, “”, “no”))

        End If

        Console.ReadLine()

    End Sub

End Module 

 

[C#]

class App

    {

        public static void Main()

        {

            Console.WriteLine(“Versión C#”);

            miControl miControl = new miControl();

            ISerializable serial = miControl as ISerializable;

            if (null != serial)

            {

                bool otroExitoMas = serial.Save();

                Console.WriteLine(“Los Datos de ‘{0}’ {1} se han guardado satisfactoriamente, con una versión optimizada”, miControl.data, (true == otroExitoMas ? “” : “no”));

            }

            Console.ReadLine();

        }

    }

La solución, con los proyectos de ejemplo pueden descargarse de Interfaces.zip

Ojalá haya servido de algo. 🙂

Asesoramiento a Organizaciones Públicas y Privadas.

Cursos a grupos ya constituidos.

Charlas de orientación.

Metodologías Ágiles.

Startups.

Visitas

  • 135,866 hits

Mejor calificado

del.icio.us