La interfaz IDisposable nos provee del método .Dispose() que utilizamos para liberar los recursos que esta usando ese objeto, pero dicho método... no deja de ser un simple método ;) Solo hace falta hacer una pequeña prueba para darse cuenta:

   1:  class Program

   2:  {

   3:      static void Main(string[] args)

   4:      {

   5:          Desechable test = new Desechable();

   6:            

   7:          test.Dispose();

   8:   

   9:          Console.WriteLine(test.Cadena??"Muerto"); // Muestra: Vivo!

  10:          Console.ReadKey(true);

  11:      }

  12:  }

  13:   

  14:  class Desechable : IDisposable

  15:  {

  16:      public String Cadena = "Vivo!";

  17:   

  18:      public void Dispose()

  19:      {

  20:   

  21:      }

  22:  }

Ok ok... un poco más complejo:

Mas...

La inicialización rápida de objetos es una nueva e interesante característica de C# 3.0, pero me gustaria reflexionar un poco sobre su uso y el de nuestros amigos los constructores.

Un constructor es el método de una instancia que implementa las acciones necesarias para inicializar la instancia de la clase, y es invocado por el operador new cuando instanciamos dicha clase.  Por lo tanto, cuando desarrollamos una clase, el ó los constructores deben de tener la capacidad de inicializar los aspectos básicos de funcionamiento del objeto.

En C#, cuando no implementamos ningún constructor, el compilador asume que tenemos un constructor sin parámetros, es decir, esto:

Mas...

Antes de empezar a desarrollar una aplicación, es conveniente revisar el diseño lógico para asegurar que es esta completo y correcto. Esto viene a ser evaluar el diseño en los siguientes terminos:

• Evaluación de ejecución:
  • Rendimiento.
  • Escalabilidad.
  • Disponibilidad.
  • Recuperación.
  • Seguridad.
• Evaluación de la arquitectura:
  • Mantenibilidad.
  • Extensibilidad.
• Evaluación de los requerimientos:
  • Casos de uso.

Mas...

Siguiendo con el tema del modelado del software en capas, es el turno de crear modelos físicos más precisos para los programadores que han de escribir el código. Los modelos físicos indican como los programadores deberían desarrollar la aplicación.

Un diagrama de componentes indica los componentes ó paquetes de los que se compondrá la aplicación y las dependencias de estos. Un componente es un conjunto de clases relacionadas formando una unidad distribuible, como una DLL, un control ó un Webservice. Los componentes se representan por rectangulos con dos pequeños rectangulos a su izquierda, en el nombre se indica la capa a la que pertenecen separados con dos dobles puntos ('::'). Otros rectangulos mayores que agrupan varios componentes simbolizan un contenedor de distribución llamado nodo, que suele indicar una separación física, como estar en distinto hardware.

Mas...

El modelado en capas de un sistema representa como se planea dividir el código en partes lógicas ó grupos. La abstracción del código en capas permite mejorar, reparar y reemplazar partes de la aplicación de forma sencilla y sin que afecte a las demás. Además provee una representación lógica y clara de la aplicación.

El modelo en capas más comun es el de tres capas, presentación, lógica de negocio y base de datos. El model n-capas extiende este modelo de forma que cualquier capa puede dividirse en subcapas, aportando así mayor claridad.

La capa más alta es en la que se interactua con el usuario, la capa más baja donde los datos son almacenados/recuperados y las capas intermedias son las encargadas de realizar el procesado de datos, el movimiento de estos de la base de datos al usuario y el control del estado de la aplicación.

Mas...

Un modelo lógico representa los conceptos reales que ha de cubrir la aplicación y permite asegurar que el software cubrirá dichos conceptos.

El modelado de funciones de objetos (Object Role Modeling - ORM) es el proceso de representar conceptos del mundo real que definen ó influyen en el software. Los diagramas ORM incluyen unos objetos primarios llamados entidades, las relaciones entre esas entidades y los atributos que definen esos objetos. Estos diagramas se crean descomponiendo los requerimientos de usuario y los casos de uso en entidades, relaciones y atributos.

Mas...

Después de evaluar los requerimientos y el diseño previo de una aplicación, el siguiente paso es realizar un prototipo.

Un prototipo tiene el propósito de cubrir los huecos  que quedan entre la teoría y la práctica, es decir, entre los requerimientos junto el diseño y la implementación real.

Las maquetas se usan para proponer y validar interfaces de usuario y la navegación por el sistema. Se pueden crear desde con papel y lapiz a herramientas como Microsoft Visio. También se conocen como prototipos horizontales y verifican el cumplimiento de los requerimientos y casos de uso a través de una serie de formularios clave.

Los prototipos de prueba de concepto prueban la arquitectura propuesta con todas sus capas, se conoce también como arquitectura de referencia. Se deben crear con las tecnologías propuestas ó aproximadas. También se conocen como prototipos verticales (por lo de que influyen todas las capas).

Mas...

Los requerimientos de un proyecto deberían ser definidos desde múltiples perspectivas:  

• Requerimientos del negocio: Definidos por los gerentes y comerciales. Exponen que puntos se consideran importantes para el éxito del proyecto.
• Requerimientos de usuario: Definidos por los futuros usuarios. Exponen que tareas deben ser capaces de realizar con la aplicación para cumplir los objetivos de su trabajo.
• Requerimientos funcionales ó especificaciones funcionales: Definidos por el lider técnico ó el arquitecto. Definen las caracteristicas que se deben desarrollar para cumplir los requerimientos anteriores. Son definidos mejor a través de herramientas de modelado, sin tener que hacer por un lado un documento de requerimientos y por otro el modelado de dichos requerimientos.
• Requerimientos de calidad de servicio: Definen requerimientos sobre el rendimiento, escalabilidad y estandares a cumplir, no sobre aspectos funcionales ó problemas específicos.

Unos requerimientos bien expuestos no deberian presentar ambiguedad. No deben exponer metas a conseguir, si no cosas que se pueden hacer y estimar. No deben dar lugar a malas interpretaciones.

Mas...

Como ya había dicho anteriormente, hay un sin fin de lenguajes con los que se pueden programar en .NET, pero no todos siguen las mismas reglas, por ejemplo, hay unos que son case-sensitive(ie:C#) y otros case-insensitive (VB) ... Imaginad que escribo una librería .dll en C# y mi cliente la usará en su proyecto ASP.NET en VB (mis dos enemigos juntos xD) ..., imaginad que en esa librería he incluido dos métodos públicos con mismo nombre y parámetros que se diferencian en que uno empieza por mayúsculas y otro en minúsculas ... ¿que pasaría al abrirlo con VB? Pues que no podría diferenciarlo.

Para esto existe el CLS (Common Language Specification), que "...es una especificación estandarizada que describe un entorno virtual para la ejecución de aplicaciones, cuya principal característica es la de permitir que aplicaciones escritas en distintos lenguajes de alto nivel puedan luego ejecutarse en múltiples plataformas tanto de hardware como de software sin necesidad de reescribir o recompilar su código fuente..." (Vía Wikipedia)

Para ayudar a cumplir con el CLS existe el atributo a nivel de ensamblado CLSCompliant, que hará que el compilador nos avise en tiempo de diseño con "Warnings" en aquellos puntos donde infringimos alguna regla del CLS. Este es uno de esos casos donde ... no cuesta tanto hacer las cosas bien :D

Mas...

Últimamente me estoy viendo más en la necesidad de usar interfaces y genéricos para crear clases más reusables y tipadas. En mis inicios con C# y .NET... aunque la idea de los genéricos me gustó... a las interfaces ... no les veia demasiada utilidad. A día de hoy soy consciente de la tremenda simbiosis que tienen estos dos elementos para crear código reusable.

Una interfaz, es como la carcasa que envuelve a un dispositivo, la carcasa no tiene funcionalidad en si, pero representa la funcionalidad que que tiene el dispositivo que en ella encaja (pensad en un acople funcional y no físico :P).

Mas...