desarrolloMobile.NET Noticias

Mostrando entradas con la etiqueta Opinión. Mostrar todas las entradas
Mostrando entradas con la etiqueta Opinión. Mostrar todas las entradas

sábado, septiembre 20, 2008

La herencia entre clases, ¿a ti te deja dormir?

Una de las malas prácticas más comunes que solemos acusar los desarrolladores es el abusivo uso de la herencia entre clases. De hecho, yo mismo en mis primeros pasos en OO con Java en la universidad, asociaba erróneamente la OO a la herencia, es decir si no hay herencia no hay OO. El supuesto o teórico despiece que debe permitir la reutilización de código gracias a la flexibilidad de esta propiedad, lo confundía con descuartizarlo de tal forma que obtenía un rompecabezas lógico de clases inmanejable e ineficiente; eso sí, el diagrama estático en UML quedaba muy bien (en apariencia visual claro).


Hace relativamente poco, hablando con un ex profesor sobre el tema en cuestión, me comentó acerca de la existencia de un principio, el Principio de Sustitución de Liskov  (LSP), el cual permite confirmar la eficiencia (no eficacia) de una herencia entre clases. LSP recibe el nombre de Barbara Liskov quién lo presentó en un seminario de OO. En la herencia se establece la subclase como “es un” (“is a”) -especificación- de la clase base y Barbara argumentó que además de “ser un”, la subclase debía “comportarse como” . Andy Hunt y Dave Thomas (The pragmatic programmer) resumieron LSP como: “Las subclases deben ser usables a través de la interfaz de la clase base sin que el usuario tenga la necesidad de conocer la diferencia.”. (Más info)


Esta misma tarde, ha tenido lugar un Webcast de Bruno, en cual he participado como oyente. Más allá del Webcast en sí, el cual ha sido brillante como no podía esperar,  Bruno ha hablado sobre el mal uso que se hace –de forma genérica- de la herencia, la cual cosa me ha llamado la atención y me ha dado pie a que, posteriormente, una vez finalizado el Webcast, le hiciera una pregunta a acerca del uso de test unitarios basados  específicos para evaluar la eficienciade la herencia, ya sea por LSP u otros técnicas. La respuesta fue buena: destacó la abstracción de interfaces –efectivamente como una aproximación válida-  y de un principio que comparto absolutamente con él: el Principio del Sentido Común.


Ahora bien, ¿Qué factores influyen en el sentido “más común” del sentido común? La experiencia, la capacidad de abstracción, los conocimiento teóricos sobre el tema,,,,, Cuando oí hablar por primera vez del LSP instintivamente analicé código hecho por mí para verificar si se cumplía dicho principio y encontré una herencia en cuestión –estoy convencido que hay más- que no lo hizo, sin embargo, dicho código forma parte de una solución funcional, está en producción. Luego, ¿es incorrecto pese a que funciona? ¿Es eficaz, pero no eficiente? ¿Podría encontrarme problemas si decidiera o requiriera extender las clases? Si es así, ¿Debo tener en cuenta al pie de la letra el LSP u otros mecanismos cada vez que confeccione un diagrama estático de clases?


Ojo, no pretendo discutir el LSP, faltaría más. La herencia llevada de forma eficiente  reduce la complejidad al desarrollador al poderse centrar únicamente en los atributos genéricos evitando tener que entrar en detalles; LSP es un principio, no como axioma sino lógico, que determina el nivel de eficiencia de la herencia entre clases y, por consiguiente, es un principio válido. Me refiero más a la línea que marcan los principios y las doctrinas académicas y las necesidades y realidades actuales.


Probablemente en este punto entre en escena las técnicas de calidad y demás. Ahí no voy a entrar; en esta comunidad hay gente que sabe mejor que yo del tema; más bien me gustaría saber vuestra experiencia u opinión al respecto, anécdotas y situaciones paranormales más allá de los libros.


En fin, ahí se queda; el próximo sábado por la noche saldré, beberé, fumaré hasta perder el conocimiento; la herencia no me quitará el sueño ;-)

viernes, septiembre 07, 2007

¿Saben cuántos móviles se vendieron durante el 2006?

Si hablara con un colega le diría... "échale", ahora les digo, "dígan algo"...

Pues se vendieron unos 1.000.000.000 de móviles...si, cuenten los zeros; tiene 9, es decir, unos mil millones de móviles en todo el mundo. Sólo en el último trimestre (Campaña de Navidad incluida) el 30%. Nokia y Motorola se repartieron la mitad del "pastelito".

Para este año algunas compañías calculan unas ventas similares al del 2006. Es decir que si buscan trabajo no descarten enfundarse de rojo, dejarse barba, teñirla de blanca y alquilar (creo que vale una pasta, aviso) un reno (una fregoneta, también vale). La industria apoya a Santa Claus , está claro, y ahora se acercan las fechas más "productivas".

lunes, junio 11, 2007

¿eres cirujano plástico.net?

Ante la inminente aceptación de WPF y Silverlight en dispositivos móviles, tablet pc, umpc (Mobile PC #Codename Origami#), smartdevice que se avecina ,explicaré mis opiniones respecto a la peculiaridades físicas de la pantalla antes de confeccionar una interfaz de usuario.

La resolución no suele ser muy grande y es, a veces, ligeramente más horizontal que un PC (p.e. 800x480 en Mobile PC). Los usuarios normalmente no utilizan teclados, sino que interactuaran con el dedo o con un lápiz táctil con lo que las zonas de selección son determinantes, entendiendo por zonas de selección (esto es la era WPF) todas aquellas partes del formulario encuadrado en la pantalla que contengan uno o varios controles que interactúen con la aplicación , botones, cajas de selección, etc. A muchos usuarios no les hará mucha gracia confundir una imagen con una zona de selección o lo que es peor no distinguir ninguna zona dentro del marco de la pantalla.

Hablando de usabilidad, traten de evitar el acercar las zonas de selección a los bordes de la pantalla. Se recomienda un tamaño aproximado de 10mm por área de selección. No permitan a un control Check Box navegar por vuestra aplicación con un tamaño inferior, no seria bueno hacer sentir al usuario, cuando éste tenga que seleccionar el valor de un Check Box, como si tuviera que tratar de 'hilar un hilo' en un alfiler. Recuerden que el ratón puede ser el dedo o el lápiz pero tampoco olviden que puede haber un teclado.

Eviten utilizar Scroll Bars. Sin embargo, como desarrollador de dispositivos móviles de plataformas Pocket PC y Smartphone yo los utilizo a menudo, pero siempre verticales. Si deciden poner que sean verticales, eso sí, cuanto menos mejor. Eviten las horizontales o lo que es peor las horizontales y verticales combinadas. No carguen la interficie gráfica en exceso. No exijan demasiado a los eventos; los botones de función que ofrece UMPC son muy bien avenidos, aprovéchenlos. Algunos Table PC ofrecen una pantalla táctil electromagnética que junto a sofisticados lápices permiten otro tipo de eventos. UMPC y Pocket PC no incorpora pantallas de ese tipo.

Las peculiaridades se centran principalmente en la pantalla y en el cambio de iteración entre ordenador y usuario en el que no hay ni teclado ni ratón, o en ocasiones sí. Por lo general los desarrolladores de dispositivos embebidos (desde Smartphone hasta Tablet PC dónde la características de las pantallas limitan las aplicaciones por motivos obvios), que son capaces de elaborar una interfície gráfica de usuario ágil, funcional y además gráficamente agradable son, para mí, auténticos 'cirujanos plásticos' del desarrollo.