11.30.07
Posted in Buenas Prácticas, Gestión del Mantenimiento, Programación at 9:52 pm by Miguel
Quisiera poner un ejemplo bastante gráfico para dejar patente la importancia de la encapsulación. Es muy bonito el concepto de encapsulación, todos lo conocemos y lo utilizamos, pero seguramente no todas las veces que deberíamos. Inicio el ejemplo:
Tenemos un objeto que controla cual es el tabulador activo en una típica ventana con pestañas, como esta. Hemos encapsulado nuestro objeto y le hemos creado un método público que se encarga que desde fuera del objeto poder elegir cual es la pestaña activa.
Algo así como: (código C#)
ObjetoTabulador tab = new ObjetoTabulador();
tab.SetPestaña(3); // 3 es el número de la pestaña que vamos a activar
Vale, está claro que esto funciona, pero no está bien encapsulado. Diseñando este objeto así estamos dando por hecho que sabemos lo que hace por dentro el ObjetoTabulador. Si yo quiero activar la tercera pestaña le paso un 3 y ese es el dato que se utiliza internamente.
¿No creéis que sería mejor solución la siguiente?
ObjetoTabulador tab = new ObjetoTabulador();
tab.SetPestaña(ObjetoTabulador.Pestañas.Informes); // informes corresponde a la pestaña de informes en el tabulador de la imagen
¿Qué ha cambiado aquí? Pues que en lugar de pasarle el número le estamos pasando un tipo enumerado que aporta el mismo ObjetoTabulador y es el que internamente va a tratar cual es la pestaña a activar. ¿Quién dice que mañana la pestaña de Informes va a seguir en la tercera posición? Si esto cambiara todas las llamadas que activan el tabulador por número pasarían a ser inconsistentes, mientras que pasándole el tipo enumerado seguiría activándose la pestaña que le habíamos indicado. Por cierto, pasándole un índice estamos dejando al descubierto que internamente estamos gestionando las pestañas con una lista.
Este error viene dado muchas veces porque cuando estamos tratando con objetos que nosotros mismos creamos y a los cuales tenemos acceso directo a partir de nuestra propia aplicación nos acostumbramos a que sabemos lo que hacen internamente y lo podemos cambiar. No resulta esta la mejor manera de programar, a la hora de desarrollar hay que pensar siempre en que los componentes que hacemos han de poder funcionar de forma totalmente independiente y que no debemos necesitar mirar su código interno para saber qué es lo que hacen.
Si con un objeto tan tonto como un control de tabulación la mejora es tan grande, (recuerdo que hemos evitado los errores que se generarían al modificar el orden de las pestañas, hemos elevado la mantenibilidad del código y la productividad del desarrollo), doy por hecho que os hacéis a la idea de lo que supondría tener en cuenta estas cosas al trabajar con objetos más complicados.
Es curioso porque cuando desarrollamos DLL’s de componentes o de objetos el concepto de encapsulación lo tenemos más claro, pero cuando utilizamos objetos propios de los cuales tenemos acceso al código fuente, se nos olvida lo de la encapsulación.
No hay que dar por hecho que para entender lo que hace una clase hay que mirar su código.
Saludos.
Miguel.
Permalink
11.29.07
Posted in Personal at 9:18 am by Miguel
Hola a todos,
Antes de nada pediros disculpas por la falta de movimiento del blog. Llevo una semana muy liado con la finalización de un proyecto muy importante.
Este proyecto del que os hablo tiene que ver con mi vida personal y el cerrarlo ha supuesto un salto hacia adelante increible, al cual he (hemos, los dos) tenido que dedicar un esfuerzo muy grande esta última semana.
Seguramente antes de que acabe la semana aparecerán nuevos posts en el blog, tengo novedades calentitas sobre cómo volver a mejorar nuestros DAO y hacerlos plenamente transaccionales al implementarlos sobre .NET.
Saludos.
Miguel.
Permalink
11.18.07
Posted in .NET, Humor at 2:11 pm by Miguel
En la empresa en la que estuve trabajando anteriormente, prácticamente dos años, tuve la oportunidad de moverme en el desarrollo de varias aplicaciones para dispositivos móviles en .NET.
Para ello, utilizábamos el Microsoft Compact Framework 2.0. Compact Framework es realmente un subconjunto de los namespace que engloba el Framework completo, adaptado a dispositivos móviles (PDA, Smartphone…).
La verdad es que para el desarrollo tampoco encontramos demasiadas fuentes de conocimiento en las que apoyarnos, almenos fiables, y tuvimos que meter mucha caña de I+D para resolver los problemas que nos íbamos encontrando. Una de esas fuentes era la página oficial del equipo de desarrollo de Compact Framework:
http://blogs.msdn.com/netcfteam/
Como podréis observar es una página donde van hablando de las actualizaciones en el framework y blablabla… pero el hilo de este post no tiene nada que ver con esto si no con la imagen que aparece en la cabecera la cual siempre me hizo mucha gracia.
¿No os parece que el tío que está en la parte inferior derecha de la foto está pegado con Photoshop? El del bigotillo que aparece de frente.
Saludos.
Miguel.
Permalink
11.15.07
Posted in Navision, Programación at 10:47 pm by Miguel
Últimamente he añadido a mis amigos a nuevos profesionales del mundo de NAVISION, por lo que en honor a ellos y a modo de guiño, cuelgo una pequeña guía de referencia del mismo. Un PDF con un cúmulo de funciones NAVISION, que tal vez para más de uno sea útil, o, para los que como yo sólo lo conocen de oidas, pues curioso 
Me ha hecho mucha gracia lo de la instrucción RANDOMIZE, me ha traido algún recuerdo que otro
Manual de Referencia Navision
Saludos.
Miguel.
Permalink
11.13.07
Posted in .NET, Patrones, Programación at 11:18 pm by Miguel
En uno de los artículos anteriores estuvimos hablando de dos patrones de diseño, DAO y DTO.
En esta ocasión vamos a partir de lo que ya conocéis de los mismos y vamos a darle una vuelta más para ver cómo podemos mejorarlo. Si lo necesitáis podéis leer el artículo anterior para poneros un poco en situación antes de leer este
Si descargáis el código fuente correspondiente al artículo anterior (Ejemplo DAO) podréis observar que el DAO hereda de BaseDAO que es la clase abstracta que contiene la conexión que maneja el DAO y algún otro método más que pueda ser útil al conjunto de nuestros DAO.
Además, si seguís echándole un ojo, veréis que CocheDAO tiene varios métodos definidos, alguno para insertar, otros para hacer selecciones… y que los nombres corresponden a GetCoche (retorna un CocheBean), GetCoches (retorna una lista genérica de CocheBean)… Si tuviéramos por ejemplo un DAO que nos ayudara a trabajar contra una entidad de datos Gato, tendríamos un GatoDAO, el cual por aproximación y estándar de nomenclatura contendría métodos como GetGato y GetGatos.
Esta es una forma con la que se puede trabajar, y llevando un estandar de nomenclatura podemos mantener una estructura clara y fácil de manejar para el equipo de trabajo.
De todas maneras, quería también dejar patente que esto es mejorable y que podemos definir mediante una interfaz (a la que llamaremos IDAO) una serie de métodos comunes que deberán implentar todos los DAO… a continuación alguno de ellos:
1) Delete
2) Insert
3) Update
4) GetOne
5) GetAll
6) Count
Todo nuestros DAO deberán implementar almenos estos cinco métodos (por el nombre más o menos se ve de lo que va la cosa).
La duda puede venir en cómo puñetas pasámos los parámetros por ejemplo a Insert y Update… ya que dependiendo de la entidad (me gustaría resaltar que en ningún momento estoy usando la palabra tabla en este ámbito, ya que precisamente el DAO lo que hace es ocultarnos cómo estamos accediendo a los datos… nadie nos asegura que esté atacando a una base de datos relacional y no lo esté haciendo a un servicio web, o a nada absolutamente) necesitaré pasar una serie de datos diferentes. Por ejemplo para la entidad coche tendría que pasar la matrícula y el número de puertas… mientras que para un gato podría pasar su nombre y su raza.
El truco está en utilizar también un interfaz con los Bean (nuestro patrón DTO, que lo llamamos bean en honor a los amantes de java) y al que llamaremos en este caso IBean.
Entonces, nuestro IDAO puede definir los métodos de una forma similar a esta (Código C#).
void Insert(IBean bean);
IBean GetOne();
List<IBean> GetAll();
void Delete(Integer id);
int Count();
Menudo truco, esto nos servirá de forma igual para que lo implementen todos nuestros DAO!
¿Y qué ventajas nos puede ofrecer el añadir Interfaces a toda esta historia a parte de mantener una estructura idéntica en todos los DAO? Pues a entre otras cosas a hacer cosas como estas (Código VB.NET)
dim Lista as List(Of IDAO) = GetListaDeDAOs()
dim total as integer = 0
for each unDAO as IDAO in Lista
total += unDAO.Count()
next
Otra ventaja es la de poder crear una Factoría de DAOs (del patrón Factory hablaremos en su momento también), cosa que podemos necesitar hacer en proyectos que alcancen cierto tamaño. Os dejo también un ejemplo (código java)
// Obtengo condición por teclado
condicion = Teclado.getCadena(”Condición:”);
// Obtengo el DAO de la factoria
InterfaceDAO dao = FactoriaDAO.getDAO( nombreTabla );
// La Select devuelve Vector
Vector vec = dao.select( condicion );
Iterator it = vec.iterator();
while (it.hasNext()) {
bean = (Bean) it.next();
System.out.println( bean.toString());
}
Para finalizar os adjunto un archivo comprimido donde he creado un pequeño proyecto donde podéis ver la definición de esto un poco en marcha.
Ejemplo DAO + Interfaces
Un saludo.
Miguel.
Permalink
11.07.07
Posted in Buenas Prácticas, Programación at 9:35 pm by Miguel
Siguiendo con las buenas prácticas hoy vamos a hablar de una que tiene que ver con la organización del proyecto, en concreto en la forma en que organizamos las clases, enumeradores e interfaces que lo forman.
Para empezar, os dejo aquí una captura de una aplicación la cual tiene todos sus compenentes sin ningún tipo de organización.
Esta forma de organizarse en principio en un proyecto pequeño puede llegar a ser sostenible, el problema viene cuando la cosa empieza a crecer y a crecer. Cuando esto ocurre la gestión de dichas clases se complica, encontrarlas por ejemplo puede hacerse complicado. Si necesito trabajar con un determinado Enumerador, tal vez me ayudaría el saber que los enumeradores los tengo encapsulados en un grupo (paquete, espacio de nombres…)… o tal vez si tengo definido una clase para acceder a un GPS, me ayudaría a encontrarla el saber que se encuentra contenida en un grupo donde se catalogan todas las clases de acceso a dispositivos externos.
Imagináos por ejemplo, los que conozcáis el framework de Java o el de .NET, si las clases en lugar de estar agrupadas en paquetes o en espacios de nombres, estuvieran todas sueltas. Nos volveríamos locos. Por eso insisto en el hecho de que aplicar esta misma organización en nuestros propios proyectos, ya no sólo mejorá en encontrar más rápido las cosas, si no que además en el hecho de que mantener nuestro proyecto organizado (en todos los sentidos) va a decir mucho de nosotros, sobre todo si el código va a pasar a ser mantenido o auditado por otros grupos de trabajo (incluso por tus propios clientes). No sólo hay que ser un buen profesional, si no que también hay que parecerlo.
Os dejo ahora una captura con las clases anteriores pero organizadas en paquetes.
Y finalmente, la agrupación, pero desplegada para que veáis qué se ha metido en cada paquete.
Otro tema a parte es cómo jerarquizar los paquetes, eso ya os lo dejo a vosotros porque va a depender de vuestra forma de trabajar o tal vez del proyecto e incluso de vuestra empresa. Con suerte tendréis estipulado cual es la jerarquía básica para vuestros proyectos y partiréis de ella.
Un saludo.
Miguel.
Permalink
11.06.07
Posted in .NET, Arquitectura, Servicios Web, Web at 10:13 pm by Miguel
Antes de nada comienzo como muchas veces dejando primero unos links a definiciones algo más concretas para luego pasar a desarrollar un poco el tema, que en este caso trata de Remoting y Servicios Web
http://en.wikipedia.org/wiki/.NET_Remoting
http://es.wikipedia.org/wiki/Servicio_Web
Es curioso porque lo de los servicios web se oye hoy en día por todas partes. Está en boca de todo el mundo, y la verdad es que hay motivos de sobra para esto ya que ha supuesto una revolución en cuanto a la arquitectura y ante la intercomunicación de sistemas desarrollados en diferentes plataformas y tecnologías. Al rey lo que es del rey, y bajo mi punto de vista los servicios web no son una moda, si no algo que realmente tiene potencia y valor. No estoy diciendo que sea la solución para todo y que después de esto no vaya a haber nada más (eso nunca pasa, al final siempre sale algo mejor), pero insisto en el hecho de que ha supuesto una verdadera revolución en la intercomunicación de sistemas.
Cuando nos ponemos a hablar de Remoting para .NET entonces la cosa ya cambia. No todo el mundo sabe muy bien para qué funciona, o tal vez ni lo hayan oido nombrar nunca. La verdad es que en parte sus razones hay, sobre todo por el hecho de que Remoting es algo que pertenece únicamente a la plataforma .NET y que está desarrollado por Microsoft y para plataformas Microsoft. Puedes hacer un servicio web en una plantaforma Java, PHP, Ruby on Rails, .NET y consumirlo desde cualquier otra plataforma, pero un servicio de Remoting vas a tener que pasar por el tubo para ponerlo en marcha tanto en la creación como en la consumición.
¿Y esto quiere decir que es mejor solución optar por los servicios web que por un servicio de remoting? Pues no, como siempre la mejor solución va a depender del problema.
A la hora de decidirse lo primero que hay que tener claro es que tanto remoting como los servicios web vienen a resolver parte de la misma problemática, es decir, encapsulan el modelo de negocio en un servidor de aplicaciones, el cual puede ser accesible desde otras aplicaciones. La lógica de la aplicación no está en la aplicación, si no en el servidor de servicios web o el de remoting. Además, mira tú por donde, podemos levantar un servicio web y un servicio de remoting en un mismo servidor web (Internet Information Server). Y encima, los dos trabajan sobre http, por lo que nos quitamos de encima todo el problema de puertos, firewall y toda la pesca. ¿Sobre la seguridad? IIS nos solventa el problema en ambos casos.
¿Entonces que les diferencia? Paso a enumerar:
1) Un servicio de remoting es más eficiente que un servicio web si serialiamos los mensajes de remoting en formato binario.
2) Un servicio web es totalmente independiente de la plataforma que lo consume ya que utiliza SOAP como estándar de comunicación.
3) Un servicio de remoting debe ser creado y consumido por aplicaciones .NET.
4) Es más sencillo crear y mantener un servicio web que un servicio de remoting.
5) Un servicio web puede utilizar únicamente http como canal de comunicación, en cambio un servicio de remoting puede trabajar también mediante TCP. Si unimos TCP+Serialización binaria es cuando conseguimos la mayor eficiencia trabajando con remoting.
6) Si utilizamos remoting mediante TCP vamos a tener que trabajarnos por nuestras cuenta todo lo referente a seguridad y autenticación, mientras que si lo montamos sobre un IIS y http, IIS nos va a resolver toda la papeleta.
Para terminar os dejo una captura de pantalla de un ejemplo de arquitectura donde Remoting y Servicios Web conviven. Como podréis observar los clientes .NET internos consumen servicios de remoting, mientras que los usuarios que acceden a través de internet consumen servicios web. Como tenemos completamente separado el modelo de negocio todo esto es posible, ¿qué bonito verdad? ¿A que mola la capa de fachada de negocio? Hablaremos un día de estos del patron de diseño Façade. ¿No os suena un poco la cosa? A simple vista parece un modelo de factoría como el que podríamo usar para diferentes bases de datos, pero aplicado a diferentes tipos de servicios.
Saludos.
Miguel.
Permalink
11.05.07
Posted in PHP, Programación, Web at 9:09 pm by Miguel
Desempolvando algo más del armario saco a la luz otra de las clases que monté en su día para gestionar usuarios, tanto su almacenamiento como su autenticación.
En su día ya veía claro que eso de gestionar usuarios no era algo que iba a hacer puntualmente para un proyecto, si no que prácticamente el 99% de las webs necesitaban gestionar a los usuarios que accedían a ella, por lo que pensé que tal vez me iría bien preparar una clase que me evitara mucho trabajo.
La idea era abstraerme de toda la parte de acceso a datos, dejando ya un script creado para una hipotética tabla usuario y toda una clase que manejara el acceso a la misma. Además, incorporé otra clase que me abstraía del uso de la variable de sesión donde almacenaba la información del usuario y además también el acceso a las cookies.
Me sigue haciendo gracia ver código de hace más de tres o cuatro años atrás
En el zip incluyo el script de creación de la tabla para una mysql, un doc con la documentación y la clase PHP4. Para su correcto funcionamiento se necesitará la clase mysql v0.3 que incluí también otro post unos días atrás.
Clase Usuario v0.1
Saludos!
Miguel.
Permalink
11.03.07
Posted in Gestión de Proyectos, Libros, Metodologías at 7:21 pm by Miguel
Otro magnífico libro de la mano de Juan Palacio, el cual nos da la oportunidad de descargar gratuitamente en PDF o adquirirlo a través de http://www.lulu.com
Os dejo el link al artículo en su blog http://www.navegapolis.net/content/view/694/61/
Saludos.
Miguel.
Permalink
Posted in Web at 7:03 pm by Miguel
Para los interesados en conocer cómo mejorar su posicionamiento en Google, os dejo un link de una web de una manera fantástica
http://google.dirson.com/posicionamiento.net/
Un saludo.
Miguel.
Permalink
« Previous entries Next Page » Next Page »
