(job) Javier Luna blog

Entre la fregona… y el chu-pa-chu…!!!

El Control de Inversión solo aparece cuando trabajas con Interfaces en Visual Studio .NET

leave a comment »

Hoy estoy con la pluma, vamos, que se sale🙂

Si desarrollas software definiendo tus propias intefaces para implementarlas en tu propio modelo de objetos, que encapsula aquella funcionalidad orientada a soportar las reglas del negocio por las cuales estas allí sentado al frente de una PC, dizque currando, pues experimentaras en carne propia la delicia de los beneficios de un código minimamente ordenado y entendible por cualquier ser humano simple, común y silvestre.

Desarrollar software es aquella fantástica oportunidad que te brinda la vida para dejar obsoleta una idea de hacer las cosas -que antes fue la hostia– y evolucionar a la siguiente preciosa idea -que sera la leche– por unas semanas mas🙂

Pero en todo ese código -que picas y picas casi encorvado sobre el teclado que gime sus gritos al sonar de cada tecla- veras que el uso de interfaces, para maquetar tu modelo de objetos, siempre fue la mejor decisión de todas.

Una decisión que contrasta de forma inversamente proporcional con la forma tradicional de hacerlo, en función a la variable: que tan preparado estas para el cambio.

Un cambio que ha de soportar TU código y que si NO haz utilizado una técnica que facilite saber como el entorno interactua con tu modelo de objetos, todo sera mas complicado al momento que venga el próximo evolutivo.

Y solo te quedara exclamar a voz en cuello, con la yugular casi a punto de reventar: “¡¡¡…Esos cambios son muy drasticos…!!!”.

En fin, el modelo de objetos que haz desarrollado orientado al producto de software que vienes implementando siempre debería ser desplegado en dos assemblies, uno de ellos SOLO llena de interfaces y la otra con tus propias clases, asumiendo que estas son, la implementación por defecto, de aquella lógica que TU haz abstraído a nivel SOLO de comportamientos y la interacción con el entorno.

Entonces, cuando empiezas a manipular solo interfaces orientadas a ese producto de software ya deberías sentirte en un nivel diferente al común de los mortales🙂

Y es allí, en la manipulación de aquellas interfaces, dizque clasesillas esqueleticas y duplicadoras de esfuerzo, que encuentras la luz: el omnipresente Control de Inversión.

Un Control de Inversión que rompe la necesidad de hacer new de las class de tu modelo de objetos, entregando esa competencia a una interfaz de orden superior que se implementara como una factory, posteriormente.

La verdad verdadera acaba de ser revelada ante vuestros ojos.

Romper el vinculo fuerte entre dos assemblies, a través de un tercero que define solo interfaces para que ese castillo de naipes que vienes edificando tenga la capacidad de ser acoplable.

NO todas las cartas utilizadas para ese castillo deberían ser siempre de la misma marca, cuando tengas que instalar aquello en algún cliente donde encontraras una realidad diferente a la que habías imaginado en TU diseño.

O del mismo modo, cuando construías estructuras extrañas con tu lego NO todas las futuras piezas tendrían que venir del misma tienda, donde compraste la primera, si solo cumpliesen la regla necesaria para acoplarse con la otra pieza.

La teoría es por demás bella y maravillosa, contrastandose siempre -casi contranatura- frente a la patética y cruda realidad.

La cruda realidad esta compuesta, allí en las empresas, con piezas de diferentes tipos y múltiples proveedores. Facilitar el acoplamientos de aquellas piezas en el producto de software que debes implementar ahora, es el reto por el cual las interfaces tienen su razón de ser y logran existir.

Amen🙂

Written by Javier Luna

septiembre 13, 2010 at 6:23 pm

Java vs. Microsoft .NET y la Guerra Santa que todos prefieren callar

leave a comment »

Este video es por demas delicioso.

Podras apreciar aquella morbosidad que se construye en lo mejor que es una tecnologia sobre otra, y como evoluciona aquella mientras la otra pierde hegemonia.

[YouTube video=http://www.youtube.com/watch?v=L7RngGThfnk]

Puedo contarles que lleve un Curso sobre Arquitectura de Soluciones Web con J2EE hace poco y la sensacion final fue de insatisfaccion por corroborar como una tecnologia NO brindaba las facilidades que uno espera encontrar para entregar soluciones de forma agil.

La interaccion con sus herramientas y el experimentar como se desarrolla software en Java NO se alejaba tanto de las epocas en que consiguio su hegemonia, hace unos años.

La verdadera batalla es Java vs C# y con LINQ se le ha dado la estocada final al viejo y cuasi-obsoleto Java.

En fin, el video intenta ser una falsa contradiccion desde la perspectiva Java. Casi una Guerra Santa.

Si existiese la pelicula con seguridad seria record de taquilla de pura gente friki🙂

Disfrutalo…!

Written by Javier Luna

julio 5, 2010 at 12:27 pm

Publicado en c sharp, desarrollo, java, software, un fontanero

Tagged with

Herencia multiple con Interfaces y Web Forms en Visual Studio .NET

leave a comment »

Las Interfaces en .NET son pocas veces usadas, por NO decir que jamas son mencionadas, en la implementacion de tu producto de software.

¿Que esta sucediendo? ¿Como te sentis al saber que NO estas utilizando todo el potencial de la tecnologia que tienes en tus manos, hablando estrictamente de C#, claro esta?

Pues VB.NET es un juguete para niños, mas nada😛

Lo que sucede es que NO le encuentras, muchas veces, razon de ser a la necesidad de definir una serie de metodos en una Interface que luego deberas implementar en cada Clase o Class que requiera implementarla.

Suena a realizar trabajo doble. A que NO ganas nada, en realidad, desde un limitado punto de vista, claro esta.

Nada mas falso que la verdad🙂

Las Interfaces tienen una valiosa utilidad. Aquella en la que ese comportamiento definido pueda ser utilizado por otras clases con la finalidad de brindar una valvula de escape al famoso, pero poco usado polimorfismo, en un lenguaje de programacion Orientado a Objetos, quimicamente NO puro, como el caso de los lenguajes de .NET😉

Por ejemplo, la interfaz IEnumerable, que por cierto es la mas utilizada por el .NET Framework, radica su valiosa utilidad en brindarle la posibilidad a la clase que la implemente en que esta pueda ser iterable sobre el famoso foreach. Omnipresente estructura de control de flujo en el C#.

IEnumerable es de un nivel primario que casi forma parte de la esencia misma del lenguaje C#.NET.

Nosotros ya NO implementamos IEnumerable en nuestras propias clases, pues existen diferentes estructuras de datos, que la implementan y nos facilitan ya esa tarea. Solo nos limitamos a usarla, a sabiendas que existe una estructura de control que la recibe para hacer algo con ella, iterarla. Hablamos del curioso foreach.

He alli la clave para la existencia de Interfaces en el modelo de clases orientadas al producto de software que estamos diseñando.

La necesidad de la existencia de una Clase a la par que defines Interfaces para que las utilizen y hagan algo con ellas, el trabajo pesado. Es decir, para que estas sean parte de la implementacion de un comportamiento de orden superior por el cual fueron concebidos.

¿Se entiende? ¿Toy hablando piedras?

Un ejemplo por favor…!

Bueno, el mas trivial de todos se encuentra en la definicion de un Modelo de Clases e Interfaces para el manejo de Web Forms y Web User Controls en productos de software con conectividad a Base de Datos.

Los Web Forms asumen la gestion de las acciones realizadas por el usuario e implementan el comportamiento, como respuesta a dichas acciones.

Los Web User Controls realizan las tareas a un nivel especifico de detalle, hacen el trabajo laborioso: asignar valores a los TextBox, llenar un DropDownList, recolectar los valores seteados de su propia estructura en un Business Entity y entregarselos a quien lo solicita, and other stuffs🙂

En ese sentido, son los Web User Controls candidatos ideales a implementar tus propias Interfaces, previamente definidas, con la intencion de centralizar ciertos comportamientos e implementarlos a nivel de Web Forms.

En concreto, tendras una clase UIPage que hereda de Page, facilitando cierta funcionalidad comunmente usada.

class UIPage : Page
{
   protected override void OnLoad( EventArgs e )
   {
       if( ! this.IsPostBack )
       {
          this.FirstRequest(); 
       }
   }

   protected virtual void FirstRequest() { }

   protected override void OnInit( EventArgs e )
   {
       this.DefineHandlers();
       this.DefineObjects();
   }

   protected virtual void DefineHandlers() { }
   protected virtual void DefineObjects() { }

   // Otras tantas funcionalidades
}

A la vez, tendras una clase UIPageForm que hereda de UIPage

class UIPageForm : UIPage
   where TForm : IForm
{
   protected virtual TForm MyForm
   {
      get { throw new NotImplementedException(); }
   }

   // Otras tantas funcionalidades
}

Asi mismo, tendras una clase UIPageEdit que hereda de UIPageForm, centralizando el comportamiento para editar los elementos de ciertas entidades de negocio.

class UIPageEdit : UIPageForm
   where TForm : IFormEdit
   where TAtom : ITransaction
{
   protected virtual TAtom MyAtom
   {
      get { throw new NotImplementedException(); }
   }

   // Otras tantas funcionalidades
}

Ahora, imaginemos que se requiere un nuevo comportamiento, por el cual al editar un Business Entity sobre el Web Form, uno de los datos ingresados por el usuario, sobre la vista o View, deba ser unico. Permitiendo la posibilidad de validar aquello a traves de una opcion especial en el View. Asi como, tambien, estrictamente validable al elegir la opcion Save.

Entonces optaremos por una implementacion como esta:

class UIPageEditValidate :
   UIPageEdit 
   where TForm : IFormEdit, IFormValidate
   where TAtom : ITransaction
{
   // Se varia el comportamiento base sobre este contexto 
   // para soportar el nuevo requerimiento.
}

Ahora, se requiere que ciertos Web Forms soporten el manejo de informacion historica por cada registro, permitiendo navegar sobre dicho historico a traves del mismo Web Form.

Este nuevo requerimiento podria aplicar tanto a Web Forms que soporten la funcionalidad de IFormValidate como a los que NO.

Aqui empieza nuestro problema, como consecuencia de la NO existencia de una herencia multiple de clases, como lo pregona aquella preciosa teoria de la POO, que tanto añoramos.

Si nuestro C# fuese un lenguaje Orientado a Objetos quimicamente puro, bastaria implementar la funcionalidad requerida sobre una clase llamada Navigator, llamada asi para efectos didacticos, y hacer que los Web Forms que requieran dicha funcionalidad la herenden, a la par que heredan su tradicional clase base, que en el mas alto nivel hereda de Page.

Pero NO es posible, una pena, entonces tendremos que buscar una forma de superar esta limitacion tecnica.

En esa busqueda, el uso correcto de Interfaces sera la solucion para este requerimiento, definiendo una interfaz INavigator y una clase llamada ControllerNavigator.

Haciendo una simple analogia, con fines didacticos, INavigator seria como IEnumerable y a su vez ControllerNavigator seria como la estructura de control foreach. Aquella que hace algo con la interfaz, que la utiliza en el contexto de la implementacion de un comportamiento de orden superior a la simple definicion de una Interfaz.

En ese sentido, tendriamos algo como esto para la interfaz INavigator:

public interface INavigator
{
   event EventHandler PreviousClicked;
   event EventHandler CurrentClicked;
   event EventHandler NextClicked;

   void StatusPrevious( Boolean enabled );
   void StatusCurrent( Boolean enabled );
   void StatusNext( Boolean enabled );
}

Por su parte la clase ControllerNavigator tendria una implementacion como esta.

public class ControllerNavigator
   where TAtom : IHasHistory, IBuildHistory
   where TForm : IFormEditHistory
{
   StateBag _viewstate;
   INavigator _navigator;
   TForm _form;
   TAtom _atom;

   public ControllerNavigator(
      StateBag viewstate,
      INavigator navigator,
      TForm form,
      TAtom atom )
   {
      this._viewstate = viewstate;
      this._navigator = navigator;
      this._form = form;
      this._atom = atom;
   }

   public void DoPreviousClicked()
   {
      // Implementacion del comportamiento requerido 
      // usando los parametros entregados
      // al instanciar ControllerNavigator
      // estando INavigator como parte de ellos.
   }

   public void DoNextClicked()
   {
      // Idem
   }
   public void DoCurrentClicked()
   {
      // Idem
   }
}

Entonces se definiran dos nuevas clases para aquellos Web Forms que requieran utilizar el comportamiento plasmado en ControllerNavigator.

Asi, tendremos las clase UIPageEditNavigator que hereda de UIPageEdit utilizando una instancia de ControllerNavigator.

public class UIPageEditNavigator :
   UIPageEdit
   where TAtom : ITransaction, IHasHistory, IBuildHistory
   where TForm : IFormEditHistory
{
   private ControllerNavigator _controller;

   protected virtual INavigator MyNatigator
   {
      get { throw new NotImplementedException(); }
   }

   protected override void DefineObjects()
   {
      this._controller = new ControllerNavigator(
         this.ViewState,
         this.MyNavigator,
         this.MyForm,
         this.MyAtom );
   }

   private void MyNavigator_PreviousClicked( Object sender, EventArgs e )
   {
      this._controller.DoPreviousClicked();
   }

   // Otras tanta funcionalidades que se ajustan con
   // lo soportado por ControllerNavigator
}

De la misma forma, definimos la clase UIPageEditValidateNavigator que hereda de la clase UIPageEditValidate utilizando una instancia de ControllerNavigator

public class UIPageEditValidateNavigator :
   UIPageEditValidate
   where TAtom : ITransaction, IHasHistory, IBuildHistory
   where TForm : IFormEditHistory, IFormValidate
{
   private ControllerNavigator _controller;

   protected virtual INavigator MyNatigator
   {
      get { throw new NotImplementedException(); }
   }

   protected override void DefineObjects()
   {
      this._controller = new ControllerNavigator(
         this.ViewState,
         this.MyNavigator,
         this.MyForm,
         this.MyAtom );
   }

   private void MyNavigator_PreviousClicked( Object sender, EventArgs e )
   {
      this._controller.DoPreviousClicked();
   }

   // Otras tanta funcionalidades que se ajustan con
   // lo soportado por ControllerNavigator
}

De esta manera, se supera la limitacion tecnica de la NO herencia multiple de clases inexistente en los lenguajes de .NET, como C#.

La clase ControllerNavigator hace el trabajo pesado de una funcionalidad que luego es posible reflejar en diferentes clases, evitando el COPY & PASTE.

Al NO lograr este nivel de abstraccion, estaremos con seguridad, dejando de utilizar todas las bondades que la tecnologia nos brinda, hablamos de la POO.

Nuestro producto de software muy probablemente este disgregado de codigo, como consecuencia irresponsable del COPY & PASTE por everywhere.

Haciendolo dolorasemente mantenible y vergonzosamente presentable🙂

Que jamas se te olvide, chaval…!

Written by Javier Luna

junio 29, 2010 at 11:07 am

Desarrollo de software basada en tres capas utilizando Visual Studio .NET

with one comment

Desarrollar software permite la posibilidad de crear, algo que NO necesariamente existe en el entorno inmediato, para reutilizar y hacer que funcione en la cruda realidad: produccion.

El entorno de produccion es aquel siniestro lugar al cual estamos sentenciados y nos dirigimos cada vez.

Diseñar una arquitectura que nos permita cierta flexibilidad y la vez rigidez en su propia base ayudara a que nuestra implementacion y posterior deployment este bajo nuestro control.

Si algo escapa de nuestro control, todo sera un dolor de cabeza, despues.

Una de estas arquitecturas es el desarrollo sobre Tres Capas, muy conocida por cierto, excesivamente utilizada y pesimamente implementada, la mayoria de las oportunidades.

En el diseño de una arquitectura, debes concebir que la capa inferior facilite las tareas de la capa superior, y que esta la utilize de manera simple y natural.

Aquella es la idea, su razon de ser.

NO debe existir redundancia de operaciones entre una capa y la otra. De lo contrario, NO tendria mayor valor NI significado su existencia.

Por ejemplo, en el clasico y trivial ejercicio, donse se requiere sumar dos numeros enteros ubicados sobre un WebForm, en el cual se debe ingresar los datos sobre un par de controles TextBox y un boton que ejecute la operacion para que se muestre el resultado en otro TextBox establecido en modo readonly, muy probablemente te encuentres con un diseño de tres capas, similar a este:

private void Sumar_Click( Object sender, EventArgs e )
{
   BLSumar o = new BLSumar();
   this.c.Text = BLSumar.Calculate( this.a.Text, this.b.Text );
}

De esta manenra, la clase BLSumar, donde BL nos quiere decir Business Layer, tendra, muy probablemente, una implementacion como esta:

public class BLSumar()
{
   public Int32 Calculate( Int32 a, Int32 b )
   {
       DLSumar o = new DLSumar();
       return o.Insert( a, b );
   } 
}

Del mismo modo, la clase DLSumar, donde DL nos quiere decir Data Layer, ajustara su implementacion en algo similar a esto:

public class DLSumar()
{
   public Int32 Insert( Int32 a, Int32 b )
   {
      Store procedure = new Store( "SP_SumarInsert" );
      procedure.AddInParameter( a );
      procedure.AddInParameter( b );
      procedure.AddOutputParameter( "c" );

      Helper.ExecuteNonQuery( procedure );
      return procedure.Parameters[ "c" ].Value;
   }
}

Asumiendo, para los efectos de la explicacion, que existe una Tabla en la Database con tres campos, donde los dos primeros seria los sumandos de la operacion y el tercero un campo calculado que obtiene la suma aritmetica de los dos primeros, entonces continuamos🙂

En este supuesto escenario, ¿cual seria la razon de ser del Business Layer que funciona de mero wrapper del Data Layer?

Recuerda que aun falta la implementacion del Store Procedure que es llamado desde la clase DLSumar, que en teoria debe realizar un simple INSERT sobre la tabla Suma.

¿Tantas clases y un store procedure para realizar una operacion tan simple?

Por Dios! Nunca fue tan laborioso realizar una operacion contra la Database🙂

Definitivamente, algo anda mal. Ten la plena seguridad que NO estamos haciendo las cosas bien.

La solucion poco decorosa de una implementacion sobre Tres capas, de esta manera, solo provoca que se gasten lineas de codigo entre una capa y otra, sin mayor valor agregado para los efectos del resultado final.

Aplicando el mismo criterio para la construccion de tus clases, en la vida real, donde te has de encontrar con un mayor numero de tablas y un abrumador numero de campos por cada tabla, entonces nos damos cuenta que nuestra solucion es una verdadera porqueria🙂

La correcta solucion pasa por darle a la implementacion de cada capa un valor agregado que facilite la vida de la capa superior. NO redundar con la misma operacion, en contextos distintos.

Una implementacion de esta manera, promueve el COPY & PASTE.

Si ello sucede en la construccion de tu producto de software, estate seguro que nuestro desarrollo camina a piñon fijo hacia una pesima escalabilidad con el codigo disgregado por everywhere.

Dolorosamente sostenible en el tiempo, dolorosamente mantenible y vergonzosamente presentable🙂

Written by Javier Luna

abril 1, 2010 at 4:20 pm

Cuando se debe utilizar interfaces en .NET usando C Sharp

leave a comment »

¿Por que usar interfaces en .NET?

Es la pregunta que siempre aflora cada vez que te encuentras implementando un modelo de clases que se ajuste a la realidad de negocio para el cual debes encontrar una solucion y en la que estas involucrado.

La Programacion Orientada a Objetos, aka POO, nos enseña que uno de los pilares de su existencia es la herencia, en sentido estricto: la herencia multiple.

La herencia multiple de clases es una bondad de la POO, pero al tocarse con la cruda realidad encuentra dificil su implementacion, sin brindarle estabilidad al modelo de clases construido.

Dificil implementacion en el sentido, de una flexibilidad atroz, que en algun momento escape de nuestro control y permita la construccion posterior de comportamientos NO concebidos por el negocio, plasmadas en la construccion de ese modelo de clases que vienes implementando.

La herencia multiple permite que pueda converger en una sola entidad diferentes comportamientos que muy probablemente colisionen sin tener mayor control sobre esa futura mutacion.

Esa flexibilidad se acota en .NET, al permitir solo la herencia simple de clases, NO la herencia multiple.

Los lenguajes de desarrollo en .NET dejan de ser, por eso, lenguajes orientado a objetos como mandan los canones🙂

Fue una decision de diseño del CLR Team y el equipo de C#, que se tomo en algun momento, luego de evaluar las debilidades de un lenguaje orientado a objetos quimicamente puro, como el precioso C++, por ejemplo.

Por su parte, la teoria de la POO, ya concebia la definicion de interfaces, de una manera distinta. Las clases abstractas son, en la actual implementacion de los lenguajes orientado a objetos, las famosas interfaces con una sutil restriccion: que cada metodo de dicha clase abstracta sea de orden publico.

Las interfaces nacen alli. Y al tener su implementacion en control de quien construye el modelo de clases, de tu producto de software, se permite a nivel de diseño heredar multiples interfaces.

Las interfaces son esa valvula de escape de un lenguaje orientado a objetos que NO permite herencia multiple de clases, con la ambicion de serlo a regaña dientes.

Pero, ¿por que usar interfaces en .NET?

Al utilizar interfaces y definirlas en nuestro modelo de clases estaremos permitiendo la posibilidad de aprovechar las bondades de un lenguaje orientado a objetos en .NET, en beneficio de una mejor implementacion del producto de software.

Una de esas tantas bondades es el polimorfismo.

¿Que beneficio encontrare al utilizar las interfaces?

Tiempo, simplemente. ¿Te parece poco, pregunto?

El uso de interfaces que definen comportamientos, que aquellas clases que las hereden deban establecer su correcta implementacion, eleva tus posibilidades de reducir los tiempos en la construccion del software, abrumadoramente.

Orientar la implementacion de tu modelo de objetos en funcion a la herencia simple de clases apoyada en la herencia multiple de interfaces, para el uso de estas en el envio de informacion entre las clases de tu propio modelo, para la definicion de tus Templates y para el manejo apremiante de delegates, te permitiran alcanzar un nivel de abstraccion, en el diseño y la arquitectura de tu modelo de clases, que se vera reflejado en reducir los tiempos para desarrollar tu producto de software y por ende los costos.

De nada sirve tipear codigo a diestra a siniestra, que promueve el COPY & PASTE por everywhere, haciendo del codigo un telaraña dolorosamente mantenible y vergonzosamente presentable.

Si NO defines tus propias interfaces en el modelo de objetos que haz diseñado, NO estaremos avanzando, solo retrocediendo.

El dolor vendra la proxima vez que tengas que meterle mano a esa basura de codigo, donde las clases que tienen comportamientos similares esten implementadas de formas totalmente distintas, sin guardar coherencia entre si, NI centralizar las lineas bases de dicho comportamiento.

Solo te quedara exclamar: Esos cambios son muy drasticos…!!!

Plop!

Written by Javier Luna

marzo 23, 2010 at 10:25 pm

Hello world!

with one comment

Es post siempre es requerido NO me preguntes ¿por que? Es un dogma de FE.

Vengaaa…!!!

Written by Javier Luna

marzo 23, 2010 at 10:05 pm

Publicado en un fontanero

Tagged with

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.