Embed Size (px)
Citation preview
Universidad Gerardo Barrio
Facultad
Ciencia y tecnología
Alumno
Walter Enrique Reyes Barahona
Tarea
Investigación
Fecha de entrega
04/03/2015
PRINCIPIO DE USABILIDAD WEB.
Usabilidad En este artículo trataremos algunos de los conceptos que se
deberíen tener en cuenta a la hora de realizar un sitio web.
Resumen: Aunque estos principios pueden parecer muy generales son
la base de la disciplina y de su extrapolaciónón y perfecta comprensaón
permite resolver cualquier casoíética concreta.
El diseño de sitios web deben seguir los siguientes principios:
1. Anticipaciónón, el sitio web debe anticiparse a las necesidades del
usuario.
2. Autónomaía, los usuarios deben tener el control sobre el sitio web. Los
usuarios sienten que controlan un sitio web si conocen su situaciónón en
un entorno abarcable y no infinito.
3. Los colores han de utilizarse con precauciónón para no dificultar el
acceso a los usuarios con problemas de distanciaón de colores (aprox.
un 15% del total).
4. Consistencia, las aplicaciones deben ser consistentes con las
expectativas de los usuarios, es decir, con su aprendizaje previo.
5. Eficiencia del usuario, los sitios web se deben centrar en la
productividad del usuario, no en la del propio sitio web. Por ejemplo, en
ocasiones tareas con mayor número de pasos son más rápidas de
realizar para una persona que otras tareas con menos pasos, pero más
complejas.
6. Reversibilidad, un sitio web ha de permitir deshacer las acciones
realizadas
7. Ley de Bits indica que el tiempo para alcanzar un objetivo con el ratoón
esta en funciaón de la distancia y el tamaño del objetivo. A menor
distancia y mayor tamaño más fácalidad para usar un mecanismo de
interacciónón.
8. Reduceón del tiempo de latencia. Hace posible optimizar el tiempo de
espera del usuario, permitiendo la realizaciónón de otras tareas mientras
se completa la previa e informando al usuario del tiempo pendiente para
la finalizaciónón de la tarea.
9. Aprendizaje, los sitios web deben requerir un mínimo proceso de
aprendizaje y deben poder ser utilizados desde el primer momento.
10. El uso adecuado de metáformas facilita el aprendizaje de un sitio web,
pero un uso inadecuado de estas puede dificultar enormemente el
aprendizaje.
11. La protecciónón del trabajo de los usuarios es prioritario, se debe
asegurar que los usuarios nunca pierden su trabajo como consecuencia
de un error.
12. Legibilidad, el color de los textos debe contrastar con el del fondo, y
el tamaño de fuente debe ser suficientemente grande.
13. Seguimiento de las acciones del usuario. Conociendo y
almacenando informaciónón sobre su comportamiento previo se ha de
permitir al usuario realizar operaciones frecuentes de manera más
rápida.
14. Interfaz visible. Se deben evitar elementos invisibles de
navegaciónón que han de ser inferidos por los usuarios, menúús
desplegables, indicaciones ocultas, etc.
Otros principios para el diseño de sitios web son:
a) Los usuarios deben ser capaces de alcanzar sus objetivos con un
mínimo esfuerzo y unos resultados máximos.
b) Un sitio web no ha de tratar al usuario de manera hostil. Cuando el
usuario comete un error el sistema ha de solucionar el problema, o en su
defecto sugerir varias soluciones posibles, pero no emitir respuestas que
meramente informen del error culpando al usuario.
c) En ningúnún caso un sitio web puede venirse abajo o producir un
resultado inesperado. Por ejemplo no deben existir enlaces rotos.
d) Un sitio web debe ajustarse a los usuarios. La libertad en el uso de un
sitio web es un téreino peligroso, cuanto mayor sea el número de
acciones que un usuario pueda realizar, mayor es la probabilidad que
cometa un error. Limitando el número de acciones al público objetivo se
facilita el uso de un sitio web.
e) Los usuarios no deben sufrir sobrecarga de informaciónón. Cuando un
usuario visita un sitio web y no sabe dónde comenzar a leer, existe
sobrecarga de informaciónón.
f) Un sitio web debe ser consistente en todos los pasos del proceso.
Aunque pueda parecer apropiado que diferentes áreas tengan diseños
diferentes, la consistencia entre los diseños facilita al usuario el uso de
un sitio.
g) Un sitio web debe proveer de un feedback a los usuarios, de manera
que éestos siempre conozcan y comprendan lo que sucede en todos los
pasos del proceso.
DISEÑO WEB LÍQUIDO O FLUIDO
Diferencias entre diseño líquido y diseño responsivo
Cada día accedemos más a internet a través de teléfonos y tabletas.
Cuando analizamos las métricas de nuestros clientes del sector de la
hostelería nos encuéntranos (mayo 2012) que aproximadamente el 40%
de las visitas a sus webs se realizan a través de teléfonos móviles. En
clientes más tradicionales observamos (octubre 2012) incrementos
mensuales del 19% en el acceso a su web con dispositivos móviles.
En España el 56% de los teléfonos móviles son Smartphone (somos el
segundo país del mundo con un porcentaje tan alto). En 2015 seremos
uno de los primeros paíseis del mundo en donde habráá más accesos a
internet desde dispositivos móviles (Smartphone y tabletas) que desde
ordenadores de escritorio. Adaptar nuestras webs a las pantallas de los
dispositivos móviles resulta ya más que necesario.
Diseño líquido o fluido (liquid or fluid layout). Una web tiene diseño
líquido o fluido cuando su tamaño se ajusta a la dimensiónón horizontal
de la pantalla de forma automática y sin necesidad de una barra de
desplazamiento horizontal (scroll). El diseño se expande al ancho
disponible de la pantalla porque el tamaño de los distintos elementos (div)
es un porcentaje del total disponible (100%) de la pantalla.
El problema surge en pantallas muy grandes como por ejemplo una TV
Full HD de 1.920 x 1080 px porque el diseño se desajusta y aparecen
grandes espacios en blanco. Pero también sufren problemas las
pantallas con resoluciones inferiores a 1.024 px de ancho (tablets en
posición portrait y móviles en posición landscape) porque las imágenes
se miniaturizan y los textos se vuelven ilegibles. Si para evitar estos
problemas se fija un ancho mínimo aparecen las barras de scroll de
desplazamiento horizontal.
Retícula de diseño líquido o fluido
Como muestra la imagen, para obviar estos problemas los diseñadores
crean versiones de layouts según la pantalla donde se vaya a visualizar
la web: pantalla de televisión, ordenador de escritorio, tablet, móvil.
Layout con un ancho mínimo de 1.420 px para pantallas Full HD TV
hasta 1.980 px
Layout con un ancho mínimo de 1.236 px y un máximo de 1.420 px para
ordenadores de escritorio con una alta resoluciónón de pantalla (por
ejemplo un iMac)
Layout con un ancho mínimo de 986 px y un máximo de 1.235 px para
ordenadores de escritorio normales
Layout para tablets con un ancho mínimo de 720 px en posición vertical
(portrait) y un máximo de 985 px para tablets en posición horizontal
(landscape)
El principal problema de un diseño líquido es el mantenimiento de
diferentes versiones de CSS. En una web con 16 páginas es más o
menos fácil. Pero un siete de comerse con más de 5.600 referencias
vivas en permanente actualizaciónón (alta y baja de productos,
versiones de color, tamaño, etc.) es realmente un suplicio.
Diseño responsiva. Se basa en la retícula (normalmente de 960 px de
ancho) que se divide en un número igual de columnas ya sean pares o
impares. Estas columnas pueden ser también eláséticas (un porcentaje
del ancho total) que hacen un ajuste aún más fino al dispositivo. La hoja
de estilos CSS3 define por medio de media quieres en queé pantalla se
visualizará la páGina en función de una serie de parámetros como:
Ancho y alto de la ventana del navegador (width, high)
Orientaciónón del dispositivo (puede ser portrait o landscape, es decir
vertical u horizontal)
Aspect-ratio (proporciónón entre el ancho y el alto de la pantalla por
ejemplo 16:9)
Grid (número de columnas que muestra)
Resoluciónón del dispositivo (densidad de píxeles que muestra la
pantalla)
Color (número de colores que representa la pantalla)
Hay cuatro parámetros más (monochrome, device aspect-ratio,
color-index, scan) que ayudan a definir con mayor exactitud el dispositivo
Responsiva grid
Responsiva web designEn función del ancho de la pantalla del
dispositivo los bloques div se ordenan y jerarquizan, de tal manera que
los elementos que estamos viendo en la imagen superior se verían en un
dispositivo móvil en una columna ordenada en la que todos los
elementos tendrían el mismo ancho.
Las ventajas del diseño responsivo son:
Con una misma web (un sólo HTML y CSS) se cubren todas las
resoluciones de pantalla
Se reducen los costes de creaciónón y mantenimiento de una web, se
acorta el desarrollo
Optimizaciónón SEO, sólo hay una URL, se ahorran las redirecciones a
otros layouts (mobile.dominio.com)
Todos los usuarios disfrutan del mismo contenido (suele ser frustrante
obtener versiones light de las webs)
De esta manera el diseño responsiva nos proporciona una
visualizaciónón controlada de la página, muy similar a la que nos ofrece
el diseño de ancho fijo.
DISEÑO WEB HIBRIDO
DISEÑO HÍBRIDO CON CSS
La maquetaciónón de una página web utilizando hojas de estilo en
cascada (css) puede hacerse mediante diseños híbridos, es decir,
combinando las diferentes opciones de maquetaciónón con css:
Diseños de ancho fijo (utilizan píxeles).
Diseños de ancho variable, llamados diseños «líquidos» o «fluidos»
(utilizan porcentajes).
Diseños eláéticos (utilizan «em»).
Los diseños híbridos combinan las tres opciones anteriores y
representan la mejor opciónón para que nuestros diseños sean
compatibles tanto con cualquier resoluciónón (tamaño) de pantalla como
con cualquier tamaño de letra. Al utilizar «em» y «porcentajes», ambas
unidades relativas, para las medidas de fuentes y cajas, cuando
aumentamos o disminuimos el tamaño de fuente en el navegador, o el
tamaño de pantalla se redimensiona automáticamente el tamaño de
todos los elementos de la página y se respeta nuestro diseño original.
Por tanto, este diseño es el ideal si pretendemos que nuestra «web» se
visualice correctamente en todo tipo de plataformas y/o dispositivos
(teléfonos móviles, celulares, ordenadores portátiles, ordenadores de
sobremesa, tabletas, etc.).
Por ejemplo, en un diseño híbrido con dos columnas, una de ellas se
expresará en porcentajes (%) para que se adapte al tamaño de la
ventana del navegador y la otra se expresará en «em» para que se
adapte al tamaño del texto.
DISEÑO WEB PARA MÓVILES
Cuando empiezas en el mundo del diseño web, tarde o temprano te
encontrarás con la necesidad de adaptar tus páginas web a los
dispositivos móviles. Actualmente cuando el número de usuarios que
navegan por internet a través de su Smartphone ha crecido
considerablemente respecto hace unos pocos años, es muy posible que
un cliente te pida adaptar su web para las pantallas móviles.
Esas capas de contenido e imágenes que diseñaste para tu última web y
que desde el navegador de tu ordenador se ve a las mil maravillas, se
descuadran o carecen de sentido en una pantalla de 320 pixeles.
Toca darle un repaso a tus hojas de estilo, a continuaciónón algunos
consejos y trucos útiles para subsanar esos posibles problemas y
adaptar el diseño de tu web, manos a la obra:
Media Quieres
Las media quieres incluidas en CSS3, te permiten filtrar estilos según
rangos de resoluciónón de pantalla en pixeles, pudiendo utilizar una
media query para los estilos específicos de tu web en la versión móvil.
Por ejemplo, dentro de un archivo.css podrías tener:
@media screen and (max-width: 490px) {
/*Estilos CSS que adaptan el diseño de tu web a dispositivos con
pantallas de un máximo
De 490 pixeles de ancho */
}
De esta forma, estos estilos serian aplicados exclusivamente a los
dispositivos móviles sin la necesidad de cargar una hoja de estilo
adicional.
También podría utilizarse una media query para cargar un archivo css
solo para determinadas resoluciones, basta con añadir entre las
etiquetas
<Head></head>:
<link rel="stylesheet" type="text/css" media="only screen and
(min-device-width: 300px)
And (max-device-width: 480px)" href="movil.css" />
En este ejemplo, el archivo movil.css solo será utilizado si el dispositivo
que se conecta a la web tiene una resoluciónón a lo ancho de entre 300 y
480 pixeles.
Utilizar medidas de tamaño relativas
Cuando colocas una imagen o cualquier otro elemento puede ser
tentador usar una medida en pixeles. Estas visualizando la web en tu
navegador de escritorio y defines un imagen con una anchura de 700px,
se ve perfectamente, pero puedes no ser consciente de que con ese
ancho la imagen se descuadra en la versión adaptada para móviles de
tu web, debido al menor ancho de pantalla.
Siempre que te sea posible, utiliza una medida relativa, en vez de la
propiedad width: 700px, utiliza porcentajes. Si utilizas width: 50%, la
imagen utilizará para desplegarse el 50% del espacio disponible dentro
de la capa en que se encuentre, reduciéndose o adaptándose el tamaño
de la imagen automáticamente según el tamaño de la pantalla en la que
se visualice. Es una de las técnicas a seguir dentro de lo que se conoce
como responsiva design.
Otra medida útil para definir el ancho y el alto es em, pues es
proporcional al tamaño de la fuente tipográfica que ve el usuario.
Herramientas para visualizar tu web en distintos dispositivos
Captura de pantalla de screenflyPara poder validar y visualizar el diseño
de tu web adaptado para distintas resoluciones de pantalla existen
herramientas como screenfly.
Introduciendo la URL de tu página podrás comprobar cómo se ve tu web
en multitud de dispositivos, distintas marcas de Smartphone y tablets.
Junto con el siempre imprescindible Firebug podrás editar los estilos y
comprobar en vivo cómo va quedando el diseño de la versión móvil de tu
sitio web.
Llevo un tiempo utilizando screenfly y el resultado ha sido satisfactorio,
pero existen otras alternativas interesantes como responsinator.
Aquíí termina la primera parte de esta mini-guía, la semana que viene
nos vemos en la segunda y última parte.
PATRONES DE DISEÑO CREACIONALES
Actionscript Masters Otros tutoriales por nestorrente.
Despuésés de la breve introducciónón a los patrones de diseño, llega el
momento de explicar los patrones de diseño creacionales.
Los patrones de diseño creacionales se centran en resolver problemas
acerca de cómo crear instancias de las clases de nuestra aplicaciónón. A
continuaciónón nos centraremos en cada uno de ellos.
Abstract Factory
El patrón Abstract Factory o Fábrica Abstracta resuelve el problema de
crear familias de objetos. Veamos un ejemplo típico de este patrón:
Imaginemos que estamos trabajando con Interfaces Gráficas de Usuario
(GUI). Pensemos que, en nuestro programa, tenemos las clases
Ventana y Botón. Pongamos, por ejemplo, que tenemos 2 interfaces
diferentes: una con colores claros y otra con colores oscuros. Esto nos
llevaríva a tener 4 clases:
Ventana Clara
Ventana Oscura
BotonClaro
BotonOscuro
Cuando el usuario decida trabajar con colores claros, se deben crear
instancias de Ventana Clara y BotonClaro. Sin embargo, si el usuario
decide utilizar la interfaz de colores oscuros, deberíamos crear
instancias de Ventana Oscura y BotonOscuro. La forma más básica de
hacerlo sería de esta manera:
Código :
// A la hora de seleccionar la interfaz
var GUI:String = "clara"; // u "oscura";
// A la hora de crear un botón
if(GUI == "clara"){
new BotonClaro();
}else if(GUI == "oscura"){
new BotonOscuro();
}
// A la hora de crear una ventana
if(GUI == "clara"){
new Ventana Clara();
}else if(GUI == "oscura"){
new Ventana Oscura();
}
Esto implicaría realizar una comprobación de la interfaz seleccionada
cada vez que se quiera crear una Ventana o un Boton.
La mejor opciónón en este caso sería utilizar el patrón Abstract Factory.
En este patrón se crean ciertas clases adicionales llamadas fábricas.
Estas clases son las encargadas de crear los diferentes tipos de
ventanas y botones. Veamos un ejemplo de su estructura:
Identifiquemos cada clase del diagrama con las clases de nuestro
ejemplo:
Cliente: Parte del programa que utilizará las fábricas y productos. Podría
ser el archivo .fla principal, por ejemplo.
IProductoA: Interfaz que define un ejemplo de producto. Se
correspondería con la clase Ventana de nuestro ejemplo.
ProductoA1 y ProductoA2: Los diferentes tipos de ese producto. Se
corresponderían con la clases VentanaClara y VentanaOscura.
IProductoB: Interfaz que define otro ejemplo de producto. Se
correspondería con la clase Boton de nuestro ejemplo.
ProductoB1 y ProductoB2: Los diferentes tipos de ese producto. Se
corresponderían con la clases BotonClaro y BotonOscuro.
IFabrica: Interfaz que define las funciones de creación de productos. En
nuestro ejemplo podría llamarse InterfazGrafica y definiría las funciones
crearVentana():Ventana y crearBoton():Boton.
Fabrica1 y Fabrica2: Clases encargadas de crear los productos. En
nuestro ejemplo, serían InterfazClara (que crearía instancias de
VentanaClara y BotonClaro) e InterfazOscura (que crearía instancias de
VentanaOscura y BotonOscuro).
Cabe señalar que podría haber más tipos de productos (Ventana, Boton,
Icono, etc.) y más familias de estos (InterfazClara, InterfazOscura,
InterfazAzul, InterfazRoja, etc.).
Una vez utilizado el patrón, el código anterior quedaría así:
Código :
// A la hora de seleccionar la interfaz
var GUI:InterfazGrafica = new InterfazClara(); // o new InterfazOscura();
// A la hora de crear un botón
GUI.crearBoton();
// A la hora de crear una ventana
GUI.crearVentana();
Según el tipo de InterfazGrafica instanciada, se crearán
ventanas/botones de un tipo u otro dinámicamente, sin necesidad de
comprobar a mano qué interfaz gráfica se está utilizando.
Builder
El patrón Builder o Constructor se utiliza cuando queremos crear un
producto que tiene diferentes partes. El siguiente ejemplo, basado en
este otro, lo ilustra mejor:
Imaginemos la cocina de una pizzería donde se hacen pizzas. Las
pizzas constan de varias partes (masa, salsa y relleno), y podríamos
tener 2 cocineros, cada uno especialista en un tipo de pizza. Esto nos
llevaría a tener 5 clases:
Cocina
Pizza
Cocinero
CocineroHawai
CocineroPicante
En una situación como esta el patrón Builder nos puede ayudar. Veamos
un ejemplo de su estructura:
Identifiquemos cada clase del diagrama con las clases de nuestro
ejemplo:
Cliente: Parte del programa que utilizará el resto de clases. Podría ser el
archivo .fla principal, por ejemplo.
Director: Clase que decide qué constructor se utiliza y cuando se debe
construir el producto. Se correspondería con la clase Cocina de nuestro
ejemplo.
IConstructor: Interfaz que define las funciones de creación de cada parte
del producto y la función de obtención del producto resultante. En
nuestro ejemplo se correspondería con Cocinero y definiría las funciones
hacerMasa():void, utilizarSalsa():void y hacerRelleno():void.
Constructor1 y Constructor2: Clases encargadas de crear las partes del
producto. En nuestro ejemplo, serían CocineroHawai y CocineroPicante.
Producto: Clase del producto en sí. Se correspondería con la clase Pizza
de nuestro ejemplo.
De esta manera, un posible código de este ejemplo sería el siguiente:
Código :
var cocina:Cocina = new Cocina();
// Decidimos que se crearán pizzas hawaianas
cocina.elegirCocinero(new CocineroHawai());
// Creamos la pizza
var pizzaHawaiana:Pizza = cocina.nuevaPizza();
El código de la clase Cocina podría ser algo así:
Código :
package {
public class Cocina {
private var cocinero:Cocinero;
public function elegirCocinero(cocinero:Cocinero):void {
this.cocinero = cocinero;
}
public function nuevaPizza():Pizza {
cocinero.hacerMasa();
cocinero.utilizarSalsa();
cocinero.hacerRelleno();
}
}
}
Opcionalmente podría definirse un constructor para la clase Cocina que
recibiese el cocinero como argumento, ahorrando la llamada a
elegirCocinero().
Factory Method
El patrón Factory Method o Método de Fábrica es una simplificación del
patrón Abstract Factory. En un patrón Factory Method sólo existe un
producto, no una familia de ellos. Veamos un ejemplo donde yo mismo
he utilizado este patrón:
Imaginemos que deseamos crear un juego estilo Tetris. En este juego
tendríamos diferentes tipos de piezas. Esto nos llevaría a tener una clase
por cada tipo de pieza:
PiezaL
PiezaT
PiezaI
...
Cada vez que se crea una pieza nueva, desearíamos seleccionar el tipo
de pieza de forma aleatoria. La forma más básica de hacerlo sería la
siguiente:
Código :
// Seleccionaríamos el tipo de pieza aleatoriamente
var tipo:uint = Math.random()*7; // 7 es el número de piezas diferentes en
el Tetris
// Creamos dicha pieza
switch(tipo){
case 1:
new PiezaL();
break;
case 2:
new PiezaT();
break;
case 3:
new PiezaI();
break;
// ...
}
Sin embargo, sería mucho más sencillo poder hacerlo de una manera
parecida a esta:
Código :
// Seleccionaríamos el tipo de pieza aleatoriamente
var tipo:uint = Math.random()*7; // 7 es el número de piezas diferentes en
el Tetris
// Creamos dicha pieza
new Pieza[tipo]();
Para poder hacer algo así debemos utilizar el patrón Factory Method.
En este patrón se utilizan fábricas, al igual que en el patrón Abstract
Factory. Estas fábricas son las encargadas de crear los diferentes tipos
de piezas. Veamos un ejemplo de su estructura:
Identifiquemos cada clase del diagrama con las clases de nuestro
ejemplo:
Cliente: Parte del programa que utilizará las fábricas y productos. Podría
ser el archivo .fla principal, por ejemplo.
IProducto: Interfaz que define el producto. Se correspondería con una
clase Pieza en nuestro ejemplo.
ProductoA y ProductoB: Los diferentes tipos del producto. Se
corresponderían con la clases PiezaL, PiezaT y PiezaI.
IFabrica: Interfaz que define las función de creación del producto. En
nuestro ejemplo podría llamarse ICreador y definiría la función
crearPieza():Pieza.
FabricaA y FabricaB: Clases encargadas de crear los productos. En
nuestro ejemplo, serían CreadorL (que crearía instancias de PiezaI),
CreadorT (que crearía instancias de PiezaT), CreadorI (que crearía
instancias de PiezaI), etc.
Una vez utilizado el patrón, el código anterior quedaría así:
Código :
// Crearíamos una lista con todas las fábricas
var creadores:Vector.<ICreador> = new Vector.<ICreador>();
creadores.push(new CreadorL(), new CreadorT(), new CreadorI());
// Seleccionaríamos el tipo de pieza aleatoriamente
var tipo:uint = Math.random()*7; // 7 es el número de piezas diferentes en
el Tetris
// Creamos dicha pieza
creadores[i].crearPieza();
De esta manera no necesitaríamos un switch, sino que se crearía la
pieza a través del creador seleccionado.
Prototype
El patrón Prototype o Prototipo resuelve el problema de duplicar objetos
ya creados con anterioridad. Veamos un pequeño ejemplo de este
patrón:
Imaginemos que tenemos un programa de dibujo por ordenador en el
cual podemos crear círculos y cuadrados. Cuando se crea un círculo,
éste tiene un radio de 50 píxeles y es de color rojo. Sin embargo,
podemos redimensionar el círculo y cambiar su color. Cuando se crea un
cuadrado, tiene 50 píxeles de lado y es de color azul. Hasta aquí todo
perfecto.
Imaginemos ahora que el usuario decide crear un círculo y modifica su
color y tamaño. Acto seguido, el usuario decide hacer una copia de dicho
círculo. El código sería el siguiente:
Código :
var circuloNuevo:Circulo = new Circulo();
circuloNuevo.color = circuloExistente.getColor();
circuloNuevo.radio = circuloExistente.getRadio();
Uno de los problemas más inmediatos de hacerlo de esta manera es que,
si se añaden nuevos atributos a la clase Circulo, habría que modificar el
código en cada lugar donde se haya hecho una copia de un Circulo.
El patrón Prototype añade un método que permita crear una copia de un
objeto. Veamos un ejemplo de su estructura:
Identifiquemos cada clase del diagrama con las clases de nuestro
ejemplo:
Cliente: Parte del programa que utilizará las fábricas y productos. Podría
ser el archivo .fla principal, por ejemplo.
IPrototipo: Interfaz que define el método clonar():IPrototipo. En nuestro
ejemplo podría ser una clase llamada IObjetoGrafico.
Prototipo1 y Prototipo2: Las diferentes clases que implementarán el
método de clonación. Se corresponderían con la clases Circulo y
Cuadrado de nuestro ejemplo.
Una vez utilizado el patrón, el código anterior quedaría así:
Código :
var circuloNuevo:Circulo = circuloExistente.clonar();
Si ahora quisiéramos añadir nuevos atributos a la clase Circulo, sólo
habría que modificar el método clonar():IPrototipo de la clase Circulo.
Por último, debe saberse que hay 2 tipos de clonación de objetos:
profunda y superficial. Imaginemos un objeto A que contenga una
referencia a un objeto B. Una clonación profunda haría que la copia del
objeto A referenciase a una copia del objeto B. Por el contrario, una
clonación superficial haría que la copia del objeto A apuntase al mismo
objeto B que el objeto A original. Esto se entiende mejor con este ejemplo
gráfico.
Singleton
El patrón Singleton se utiliza para no permitir que existan múltiples
instancias de una clase, sino solamente una. Veamos un pequeño
ejemplo de este patrón:
Imaginemos un programa que, al hacer click en un icono de ayuda, cree
una ventana nueva con los documentos de ayuda del programa.
Normalmente, si el usuario hiciese click en el botón nuevamente, se
abriría una nueva ventana, y así sucesivamente.
Sin embargo, podríamos desear que, si la ventana de ayuda ya ha sido
abierta, no se abra de nuevo. Para ello recurriríamos a un patrón
Singleton, que aseguraría la existencia de una única ventana de ayuda
en todo momento.
Veamos un ejemplo de la estructura del patrón Singleton:
Identifiquemos cada clase del diagrama con las clases de nuestro
ejemplo:
Cliente: Parte del programa que utilizará las fábricas y productos. Podría
ser el archivo .fla principal, por ejemplo.
Singleton: Clase que se quiere instanciar una sola vez. Se corresponde
con la clase VentanaAyuda de nuestro ejemplo.
La forma de implementar el patrón Singleton en este ejemplo sería
dotando a la clase VentanaAyuda de un método estático
getInstancia():VentanaAyuda que comprobase si ya existe una instancia
VentanaAyuda o si, por el contrario, se debe crear. De esta manera, el
código para crear una nueva VentanaAyuda sería el siguiente:
Código :
var ayuda:VentanaAyuda = VentanaAyuda.getInstancia();
Sin embargo, debemos evitar que el usuario pueda crear instancias de
VentanaAyuda mediante el constructor new VentanaAyuda(). La forma
idónea de hacerlo es declarando el constructor como privado, de modo
que no pueda ser llamado desde fuera de la clase VentanaAyuda. El
problema es que ActionScript, de momento, no permite la declaración de
constructores privados. Podemos solucionarlo de la siguiente manera:
Código :
package {
public class VentanaAyuda{
// Esta variable guardará la única instancia de ésta clase
// que existirá en el programa
private static var instancia:VentanaAyuda;
// Ésta variable servirá para saber cuándo el constructor
// es invocado desde fuera de la clase
private static var llamadaInterna:Boolean;
// Constructor
public function VentanaAyuda(){
// Comprobamos si la llamada se ha producido
// desde fuera de esta clase
if (!llamadaInterna){
// Si se ha intentado instanciar la clase desde el
// exterior, la aplicación devolverá un error y no
// se creará ninguna instancia de VentanaAyuda.
throw new Error("Debes usar getInstancia()");
}
}
// Método que instanciará la clase una sola vez
public static function getInstancia():VentanaAyuda {
// Comprobamos si la instancia no se ha creado todavía
if (instancia == null) {
// Especificamos que la llamada
// al constructor es interna
llamadaInterna = true;
// Guardamos en la variable "instancia"
// una instancia de esta clase
instancia = new VentanaAyuda();
// Especificamos que las llamadas
// posteriores no serán internas
llamadaInterna = false;
}
// Por último, devolvemos la instancia existente
return instancia;
}
}
}
Observemos ahora el efecto que produciría este código de ejemplo:
Código :
new VentanaAyuda(); // Se devolvería un error y no se instanciaría la
ventana
VentanaAyuda.getInstancia(); // Se devolvería una nueva instancia de
VentanaAyuda
VentanaAyuda.getInstancia(); // Se devolvería la instancia ya existente
que se creó en la linea anterior.
Patrones de comportamiento
PATRONES DE COMPORTAMIENTO
Cuando ciertas reacciones de la persona, se hacen muy
frecuentes en determinados
ambientes o situaciones, constituyen lo que llamamos un patrón
de comportamiento. Un
patrón de comportamiento es una forma constante que tiene una
persona, de
pensar, sentir, reaccionar físicamente y actuar en determinada
situación.
Nuestros patrones de comportamiento tienen el siguiente origen:
Los copiamos o aprendemos de las personas que han compartido
la vida con nosotros:
padres, abuelos, tíos, maestros y de cualquier personaje
importante con el cual hayamos
tenido un contacto significativo a través de la TV, cine, videos,
iglesia, paseos, retiros
espirituales, etc. , sean estos personajes seres humanos,
animales o dibujos animados.
Provienen de nuestras propias reacciones: esto quiere decir, que
guardamos dentro de
nosotros las reacciones que tenemos frente a otros o aún ante
animales, dibujos animados,
películas y frente a la naturaleza (un río, una montaña, la lluvia,
truenos, relámpagos,
tormentas, huracanes, etc.).
También grabamos y guardamos nuestras reacciones cuando
satisfacemos o no las
necesidades y deseos. Nuestras diversas reacciones frente al
hambre, sed, contacto,
compañía, afecto, seguridad, protección, etc.
Todo queda guardado para ser utilizado en cualquier momento.
Lo anterior significa que:
1. Todo lo que vemos y oímos lo captamos a nuestra propia manera y lo
guardamos en
nosotros, para ser utilizado algún día, para bien o para mal
2. Todas las reacciones ( ideas, pensamientos, imágenes, emociones,
sentimientos, y
sensaciones físicas ) , que suceden o se dan en nuestro ser, quedan
guardadas en los registros
o “archivos” que Dios ha creado en el organismo de cada ser humano.
Algún día utilizaremos
estas “grabaciones” y quedarán expuestas ante nosotros y muchas
veces ante otros.
Un patrón de comportamiento puede ser constructivo o destructivo, y
tiene los siguientes
Cuatro (4) componentes:
1. PENSAMIENTOS, CREENCIAS E IDEAS.
2. EMOCIONES Y SENTIMIENTOS E IMÁGENES.
3. CONDUCTAS.
4. REACCIONES DEL CUERPO ( Tensión, poca energía, mareos,
parálisis, temblores,
vómitos, diarreas, estrés, otras reacciones fisiológicas y reacciones
neurológicas)
PATRONES CONSTRUCTIVOS
1.REALISTA O RACIONAL-OBJETIVO
Conductas apropiadas a la situación, sentimientos de paz y seguridad,
actitud firme, palabras claras, con un tono de voz y volumen apropiado.
Sus afirmaciones y juicios se basan en hechos comprobados. Mira las
cosas como realmente son.
2. CRÍTICO POSITIVO.
Se esfuerza porque hayan y se respeten límites y reglas razonables. Es
firme y consistente en sus juicios, que se basan en hechos
comprobados. Es protector y justo cuando aplica disciplina. No
maltrata, ni humilla.
3. ADAPTADO SANO.
Cumple las reglas y normas aunque le cause malestar. Hace lo que haya
que hacer, aunque no le guste, lo hace de buen ánimo y manera
correcta, como si fuera para Dios. Se deja proteger. Es responsable y
cumplidor de sus deberes. Cuida todo lo que es suyo y participa en el
cuidado de los otros y del ambiente.
4. NUTRITIVO POSITIVO.
Está pendiente y ayuda en la satisfacción de las necesidades de las
otras personas y también de sus propias necesidades. Apoya,
estimula y alienta a los demás y se da a sí mismo aliento, estímulo y
reconocimiento. Identifica sus recursos y los utiliza con talento y
sabiduría.
5. NATURAL Y ESPONTÁNEO.
Tiene conciencia de lo que está sintiendo y lo expresa sanamente.
Siente y expresa las emociones y sentimientos agradables (amor, y
alegría) y las que son desagradables como rabia, miedo y tristeza. Está
familiarizado con su cuerpo y con sus necesidades. Disfruta sin
arriesgarse, ni dañar a otros.
PATRONES DESTRUCTIVOS
1. CRÍTICO NEGATIVO.
Para los críticos negativos, los otros están mal y sólo ellos están bien.
Acostumbran hacer juicios o críticas de valor sobre los otros. Resaltan
constantemente las fallas y faltas de los demás. Se inventan cualquier
razón para no dar reconocimiento positivo a los demás.
2. SOBREPROTECTOR.
Atiende exageradamente las necesidades de los demás y desatiende las
propias. No pregunta, ni oye para conocer las necesidades de los otros,
las
asume. Funciona como un adivino o una especie de dios, que cree saber
lo
que los demás necesitan y se jacta de eso.
3. REBELDE.
Se opone a las autoridades, a las reglas, normas y regulaciones. No se
deja
proteger, porque no acepta consejos, ni sugerencias. Mantiene la actitud
de
ser sabio de su propia opinión. Sus conductas predominantes son la
agresividad, la violencia y el aislamiento. Su emoción preferida es la ira.
4 SERVIL O FÁCIL DE DOMINAR
Actúa según lo que cree que son las expectativas de los demás, para
complacerles y ganarse así el afecto, aceptación y respeto de ellos. Es
asustadizo, inseguro, débil y depresivo. Mantiene creencias y actitudes
de
pesimismo y derrota. Es constantemente negativo. No utiliza los
recursos
que Dios le ha dado para su protección y desarrollo
5. VENGATIVO O RENCOROSO.
Le cuesta perdonar porque recuerda constantemente lo que una vez
alguien
le dijo, le hizo o dejó de hacerle o de decirle. Cultiva la venganza hacia
los
otros y la lleva a cabo a cualquier costo y de cualquier manera.
Predomina
en estas personas el resentimiento, la rabia, el rencor y la actitud
vengativa.
PATRONES DE DISEÑO SOFTWARE ESTRUCTURALES
Introducción
Los patrones de diseño estructurales están enfocados en la gestión de la
forma en la que las clases y los objetos se combinan para dar lugar a
estructuras más complejas. Al igual que en las otros tipos de patrones,
podemos hablar de patrones estructurales asociados a clases (Adapter)
y asociados a objetos (Bridge, Composite, Decorator, Facade, Flyweight,
Proxy). Los primeros utilizan la herencia mientras que los segundos se
basan en la composición. Los patrones estructurales asociados a objetos
describen formas de componer los objetos para conseguir nuevas
funcionalidades. La flexibilidad de la composición de estos objetos surge
de la posibilidad de cambiar dicha composición en tiempo de ejecución,
lo que es imposible con la composición estática tradicional de clases.
Adapter
El patrón Adapter convierte la interfaz de una clase en la que otra
necesita, permitiendo que clases con interfaces incompatibles trabajen
juntas.
Por lo tanto, el uso de este patrón estructural está indicado cuando se
quiere usar una clase ya implementada y su interfaz no es similar con la
necesitada o cuando se desea crear una clase reusable que coopere con
clases no relacionadas o que tengan interfaces compatibles.
Sin embargo, hay que hacer distinción entre si queremos adaptar un
objeto o una clase o interfaz completa.
Un adaptador de clase adapta la clase Adaptee a la interfaz de la clase
Target, trabajando con una clase adaptada concreta. Por ello, una clase
adaptadora no funcionará cuando se desee adaptar, además de la clase
objetivo, todas sus subclases.
Sin embargo, un adaptador de objetos permite que un único Adapter
trabaje con muchos Adaptees. De este modo, el Adapter también puede
agregar funcionalidad a todos los Adaptees de una sola vez.
Los participantes de este patrón serían los siguientes:
Client: Es el principal agente en la formación de objetos para la interfaz
Target.
Target: Interfaz del dominio específico que usa el Client.
Adaptee: Es la interfaz ya existente que necesita adaptarse.
Adapter: Es quien adapta la interfaz del Adaptee a la interfaz Target.
Este sería el diagrama de clases general del patrón:
Esquema Adapter
Esquema del patrón Adapter
En este enlace podrá consultar un código de ejemplo en Java del patrón
Adapter.
Composite
El patrón Composite sirve para construir objetos que estén formados por
tros objetos más simples, pero siempre similares entre sí, gracias a la
composición recursiva. Por lo tanto, al tner todos estos objetos una
misma interfaz, el Composite simplifica el tratamiento de los mismos.
El patrón composite es ampliamente usado en el tratamiento de
interfaces de usuario en las que se necesita, por ejemplo, representar un
conjunto de elementos de una interfaz gráfica. Algunos de estos
elementos serán simples, mientras que otros serán más complejos y
estarán formados por varios elementos simples. Por tanto, el
comportamiento y/o la información que proporciona un elemento
complejo está determinada por los elementos que lo componen.
Generalizando, nos encontraríamos frente a una situación en la que
neceistaríamos representar jerarquías de objetos de tipo parte y
compuestos en la que se quiere usar la misma interfaz en las partes y en
los compuestos. El patrón Composite, lo que nos ofrece es crear una
interfaz o clase abstracta que actúe comosuperclase de las clases
concretas que representan las partes y los compuestos. Las clases que
representan los compuestos pueden ser tratadas como partes, porque
soportan la interfaz.
De este modo, encontramos que los componentes del patrón serían los
siguientes:
Client: Manipula objetos atravez de la interfaz proporcionada por
Component.
Component: Declara la interfaz para los objetos de la composicion, es la
interfaz de acceso y manipulacion de los componentes hijo e implementa
algunos comportamientos por defecto.
Composite: Define el comportamiento de los componentes compuestos,
almacena a los hijos e implementa las operaciones de manejo de los
componentes.
Leaf: Definen comportamientos para objetos primitivos del compuesto.
Según esto, este sería el diagrama de clases general del patrón:
Esquema Composite
Esquema del patrón Composite
En este enlace podrá consultar un código de ejemplo en Java del patrón
Composite.
Decorator
El patrón de diseño estructural Decorator facilita la tarea de añadir
dinámicamente funcionalidades a un Objeto. De este modo, elimina de
necesidad de crear clases que fuesen heredando de la primera,
incorporando no sólo la nueva funcionalidad, sino también otras nuevas
y asociarlas a ella.
A veces se desea adicionar responsabilidades a un objeto pero no a toda
la clase. Las responsabilidades se pueden adicionar por medio de los
mecanismos de Herencia, pero este mecanismo no es flexible porque la
responsabilidad es adicionada estáticamente. La solución flexible es la
de rodear el objeto con otro objeto que es el que adiciona la nueva
responsabilidad. Este nuevo objeto es el Decorator.
Este ejemplo de patrones estructurales de diseño software es útil
cuando:
- Queremos añadir o expander las funcionalidades de objetos de forma
dinámica y transparente.
- Necesitamos que ciertas responsabilidades de un objeto puedan ser
retiradas de forma sencilla en un futuro.
- No es posible o no compensa realizar esta expansión de
funcionalidades mediante herencia.
- Existe la necesidad de expandir dinámicamente la funcionalidad de un
objeto y/o eliminar la funcionalidad extendida.
Visto esto, señalar que los participantes de este patrón serían los
siguientes:
Component: Define la interface de los objetos a los que se le puede
adicionar responsabilidades dinamicamente.
ConcreteComponent: Define el objeto al que se le puede adicionar una
responsabilidad.
Decorator: Mantiene una refeencia al objeto Component y define una
interface de acuerdo con la interface de Component.
ConcreteDecorator: Es el encargado de sumar la responsabilidad al
componente. Puede haber varipos ConcreteDecorator.
Por lo tanto, este sería el diagrama de clases general del patrón:
Esquema Decorator
Esquema del patrón Decorator
En este enlace podrá consultar un código de ejemplo en Java del patrón
Decorator.
Proxy
Esta patrón estructural tiene como propósito proporcionar un
intermediario para controlar el acceso a un objeto. Por ello tiene distintas
aplicaciones:
- Proxy Remoto: Denominado así cuando representa a un objeto remoto.
- Proxy Virtual: Usado para crear objetos bajo demanda.
- Proxy de Referencia "inteligente": Cuando sirve como sustituto de un
puntero que realiza operaciones adicionales cuando accede al objeto.
- Proxy de Protección: Denominado así cuando se usa para controlar el
acceso al objeto original.
La finalidad principal del patrón de diseño estructural Proxy, sería
proporciona un representante o sustituto de otro objeto para controlar el
acceso a éste. Esto lo hace según la motivación deMotivación: retrasar el
coste de crear e inicializar un objeto hasta que sea realmente necesario.
Por lo tanto, es usado cuando se necesita una referencia a un objeto más
flexible o sofisticado que un puntero. Por ejemplo, si que queremos
construir una aplicación que usa muchos objetos visuales, lo ideal es que
dichos objetos sólo se instanciaran cuando se vayan a utilizar, de tal
forma que se ahorre carga en memoria y tiempo.
Con esto, las clases participantes en el patrón, serían las siguientes:
Proxy: Mantiene una referencia al objeto real, mientras que proporciona
una interfz idéntica a la del objeto real (Real Subject) y controla el acceso
a este objeto, siendo responsable de crearlo y borrarlo.
Subject: Define una interfaz común para el proxy y el objeto real.
RealSubject: Clase del objeto real que el proxy representa.
Según esto, este sería el diagrama de clases general del patrón:
