You are currently browsing the category archive for the 'Visual Studio' category.
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
A partir de la versión 2.0 del Framework .NET contamos con el namespace Generics que define una cantidad de clases e interfaces que permiten administrar sub ítems en una variedad de contenedores. En este post me voy a dedicar al contenedor List<T> o List(Of T) según sea C# o VB.NET
Veamos un ejemplo de colección sin Generics. Con Visual Studio .NET, abrimos un nuevo proyecto de Consola, si queremos manipular un conjunto de objetos, por ejemplo Libros, en primer lugar tenemos que referenciar lo siguiente:
C#
using System;
using System.Collections;
VB.NET
Imports System
Imports System.Collections
y definir 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
Además, necesitamos programar otra clase, por ejemplo BibliotecaCollection que implemente la intefaz IEnumerable. En nuestro caso le agregaremos un método AgregarLibro que recibe un parámetro de tipo Libro y lo agrega a un ArrayList que la clase encapsula.
El tipo ArrayList en el namespace Collection, es el equivalente al tipo List<T> o List(Of T) del namespace Generics
C#
public class BibliotecaCollection : IEnumerable
{
private ArrayList arBiblioteca = new ArrayList();
public BibliotecaCollection() { }
public void AgregarLibro(Libro pLibro)
{
arBiblioteca.Add(pLibro);
}
IEnumerator IEnumerable.GetEnumerator()
{
return arBiblioteca.GetEnumerator();
}
}
VB.NET
Public Class BibliotecaCollection
Implements IEnumerable
Private arBiblioteca As ArrayList = New ArrayList
Public Sub New()
MyBase.New()
End Sub
Public Sub AgregarLibro(ByVal pLibro As Libro)
arBiblioteca.Add(pLibro)
End Sub
Function IEnumerable_GetEnumerator() As IEnumerator Implements IEnumerable.GetEnumerator
Return arBiblioteca.GetEnumerator
End Function
End Class
Cualquier otro tipo de función que queramos que soporte la clase, debemos codificarla. Para este ejemplo sólo vamos a dejar definida la función AgregarLibro.
Ahora si podemos hacer uso de nuestra biblioteca en una aplicación de consola:
C#
class Program
{
static void Main(string[] args)
{
Console.WriteLine(“Collections\n”);
BibliotecaCollection miBiblioteca = new BibliotecaCollection();
miBiblioteca.AgregarLibro(new Libro(“Trópico de Cáncer”, “Henry Miller”));
miBiblioteca.AgregarLibro(new Libro(“Yonqui”, “William Burrougs”));
miBiblioteca.AgregarLibro(new Libro(“Esperando a Godot”, “Samuel Beckett”));
miBiblioteca.AgregarLibro(new Libro(“La senda del perdedor”, “Charles Bukowski”));
miBiblioteca.AgregarLibro(new Libro(“En el camino”, “Jacques Kerouac”));
foreach (Libro pLibro in miBiblioteca)
Console.WriteLine(pLibro);
Console.ReadLine();
}
}
VB.NET
Module Module1
Sub Main()
Console.WriteLine(“Collections”)
Dim miBiblioteca As BibliotecaCollection = New BibliotecaCollection
miBiblioteca.AgregarLibro(New Libro(“Trópico de Cáncer”, “Henry Miller”))
miBiblioteca.AgregarLibro(New Libro(“Yonqui”, “William Burrougs”))
miBiblioteca.AgregarLibro(New Libro(“Esperando a Godot”, “Samuel Beckett”))
miBiblioteca.AgregarLibro(New Libro(“La senda del perdedor”, “Charles Bukowski”))
miBiblioteca.AgregarLibro(New Libro(“En el camino”, “Jacques Kerouac”))
For Each pLibro As Libro In miBiblioteca
Console.WriteLine(pLibro)
Next
Console.ReadLine()
End Sub
End Module
Ahora, con Generics, no necesitamos de la clase BibliotecaCollection, ni implementar la interfaz IEnumerable, ni el método adicional AgregarLibro.
Sólo necesitamos declarar una lista genérica de Libros de la siguiente forma:
C#
List<Libro> miBiblioteca = new List<Libro>();
VB.NET
Dim miBiblioteca As List(Of Libro) = New List(Of Libro)
Tenemos que modificar levemente las referencias a:
C#
using System;
using System.Collections.Generic;
VB.NET
Imports System
Imports System.Collections.Generic
Y con la misma declaración de la clase Libro que tenemos más arriba usamos nuestra lista genérica de Libros de esta forma:
C#
class Program
{
static void Main(string[] args)
{
Console.WriteLine(“Generics\n”);
List<Libro> miBiblioteca = new List<Libro>();
miBiblioteca.Add(new Libro(“Trópico de Cáncer”, “Henry Miller”));
miBiblioteca.Add(new Libro(“Yonqui”, “William Burrougs”));
miBiblioteca.Add(new Libro(“Esperando a Godot”, “Samuel Beckett”));
miBiblioteca.Add(new Libro(“La senda del perdedor”, “Charles Bukowski”));
miBiblioteca.Add(new Libro(“En el camino”, “Jacques Kerouac”));
foreach (Libro pLibro in miBiblioteca)
Console.WriteLine(pLibro);
Console.ReadLine();
}
}
VB.NET
Module Module1
Sub Main()
Console.WriteLine(“Generics”)
Dim miBiblioteca As List(Of Libro) = New List(Of Libro)
miBiblioteca.Add(New Libro(“Trópico de Cáncer”, “Henry Miller”))
miBiblioteca.Add(New Libro(“Yonqui”, “William Burrougs”))
miBiblioteca.Add(New Libro(“Esperando a Godot”, “Samuel Beckett”))
miBiblioteca.Add(New Libro(“La senda del perdedor”, “Charles Bukowski”))
miBiblioteca.Add(New Libro(“En el camino”, “Jacques Kerouac”))
For Each pLibro As Libro In miBiblioteca
Console.WriteLine(pLibro)
Next
Console.ReadLine()
End Sub
End Module
Como vemos en el namespace Generics se resuelve todo lo que antes debíamos codificar en una clase adicional, en este ejemplo BibliotecaCollection.
Los otros contenedores del namespace que no cubro en este post son:
Collection<T>, la base de una colección genérica,
Comparer<T>, Comparación de igualdad entre dos objetos genéricos,
Dictionary<K, V>, colección genérica de pares nombre/valor,
Queue<T>, implementación genérica de lista FIFO (first-in, first-out),
SortedDictionary<K, V>, implementación genérica de un conjunto ordenado de pares nombre/valor,
Stack<T>, implementación genérica de lista LIFO (last-in, first-out),
LinkedList<T>, implementación genérica de una lista doblemente vinculada,
ReadOnlyCollection<T>, implementación de un conjunto de items genéricos de sólo lectura.
En fin, contamos con una nueva serie de elementos para aprovechar la potencia del Framework.
TDD, Test Driven Development, es una técnica que establece que primero se escriben las pruebas y luego el código del aplicativo.
Estas pruebas se efectúan de acuerdo a lo que se espera que haga el aplicativo, es por eso que algunos popes de esta disciplina dicen que practicándola intensivamente podemos prescindir de la documentación ya que el código de las pruebas es en si mismo documentación acerca del aplicativo.
En otras palabras las pruebas especifican lo que se espera de la aplicación a desarrollar.
Esta práctica es de amplia difusión en las Metodologías Ágiles, con esto se garantiza código de calidad desde el inicio del proceso de desarrollo y proporciona un buen elemento para el establecimiento de métricas.
El Ciclo TDD se compone de los siguientes pasos:
- Escribir un test, aún de algo que todavía no hayamos codificado,
- Compilar, va a dar error, ya que todavía no hemos codificado lo que estamos probando,
- Escribir la mínima cantidad de código para que compile, aunque sea la cabecera del método o función a probar,
- Compilar, ahora no da error, estamos en condiciones de ejecutar nuestro Test,
- Ejecutar el test, falla, ya que habíamos escrito la mínima cantidad de código que garantice la compilación, pero no la ejecución del Test,
- Escribir la mínima cantidad de código para que el Test no falle,
- Ejecutar el test, esta vez no falla,
- Refactorizar, este es un tema aparte, hay variadas técnicas de refactorización y muchos buenos libros escritos, más adelante veremos someramente alguna de esas técnicas,
- Recomenzar escribiendo un nuevo Test.
Es habitual encontrar TDD asociado a estas tres palabras en sus respectivos colores:
Red, Green, Refactor…
Estos son términos y colores asociados a la familia de herramientas de Test Unitarios xUnit, dela que usaremos NUnit, se pueden descargar la última versión desde http://www.nunit.org, también van a encontrar documentación.
Red, está asociado a la ejecución fallida de uno o más Tests.
Green, es el color que se ve en la IDE de NUnit al ejecutar exitosamente uno o más Test.
Refactor, lo podemos ver cuando estamos refactorizando nuestro proyecto de Testing.
Es muy importante que las modificaciones se hagan en pequeños pasos, esto hace a la estabilidad del código probado a lo largo del proceso de desarrollo. Una buena estrategia de Testing evita los grandes objetos, los Test integrales, la interdependencia entre las pruebas.
Una buena estructura TDD tiende a que el equipo de desarrollo esté más y mejor comunicado. Como se elimina la probabilidad de romper funcionalidad existente al liberar código nuevo, se eliminan temores a “papelones”.
La Barra Verde que nos muestra NUnit cuando los Test son exitosos se convierten en un factor motivacional positivo.
Por su propia naturaleza, TDD elimina los problemas derivados de las contínuas postergaciones del Debugging.
¿Y?… ¿cómo se hace?…
Te pido que me esperes a que termine el próximo post.
