VARIACIONES RESTRINGIDAS

Principio fundamental que motiva la mayora de los mecanismos y patrones en la programacin y el

diseo, destinados a proporcionar flexibilidad y proteccin frente a las variaciones.
Este patrn para sistemas orientados a objetos es tambin conocido como la Ley de emeter, donde
solamente se permite !la c"arla con los amigos# Esta regla fue propuesta por la $niversidad del noreste
de %oston en &'() por *an +olanda. Este proyecto fue nombrado en el "onor de emeter, diosa de la
agricultura.
Esta ley es un caso especfico del principio del bajo acoplamiento, slo que se intenta mirar de una
manera m,s especifica. La motivacin que se tuvo para para la creacin de la ley de emeter es el
control de la sobrecarga en la informacin- podemos mantener solamente un sistema limitado de
artculos en la memoria a corto pla.o y es m,s f,cil mantenerlos en memoria si se relacionan de cerca.
Problema
/adica en 01mo disear sistemas de manera que las variaciones en estos elementos no tenga impacto
no deseable en los otros elementos2, es decir, a quin se le debe asignar la responsabilidad para evitar el
conocimiento sobre la estructura de objetos indirectos2
3i un objeto tiene conocimiento de las conecciones internas y la estructura de otros objetos, entonces
est, presentando alto acoplamiento. 3i un objeto cliente tiene que usar un servicio, o se tiene que
obtener informacin de un objeto indirecto, cmo se debe "acer esto sin presentar acoplamiento para
conocer la estructura interna de su servidor directo u objetos indirectos2
Solucin
3e deben identificar los puntos de variacin prevista y crear interfaces estables alrededor de ellos.
4signando la responsabilidad a un objeto directo del cliente para que colabore con el objeto indirecto,
el cliente no necesita conocer nada acerca del objeto indirecto.
Este patrn implica que los objetos directos pueden requerir nuevas operaciones que act5en como
operaciones intermediarias, de esta manera el cliente va a evitar !"ablar con extraos#.
Ejemplo
En una aplicacin de un punto de venta, se asume que la instancia POST tiene un atributo referenciando
a Sale, el cual a su ve. tiene un atributo referenciando a Payment.
Diseo parcial del diagrama de clases
3e asume que6
La instancia POST soporta la operacin paymentAmount, el cual retorna la actual cantidad ofrecida
para el pago.
La instancia Sale soporta la operacin payment, el cual retorna la instancia 7ayment asociada a Sale.
$na forma de retornar la cantidad pagada es6
Viola el principio de no hablar con extraos
La anterior muestra una violacin al principio !no "able con extraos#, debido aque la instancia POST
esta enviando un mensaje a un objeto indirecto 87ayment no es uno de los cinco candidatos familiares#8
La solucin, como el patrn lo sugiere, es dar la responsabilidad a un objeto directo 8en este caso 3ale8
para retornar la cantidad pagada a POST. Esta es una solucin general para soportar este principio.
4dem,s, una operacin paymentAmount fue adicionada a Sale para que POST no tuviera que !"ablar a
un extrao#. Esto se muestra en la siguiente figura6
Soporta el principio no hablar con extraos
ecani!mo! "#!ico!$
Diseo dirigido por los datos: 3e protege al sistema del impacto de las variaciones de los datos
registrando exactamente la variante.
Bsqueda de servicios: 3e protegen los clientes de las variaciones en la ubicacin de los servicios,
utili.ando una interfa. estable de la b5squeda del servicio.
Diseo dirigido por un intrprete: 3e protege al sistema del impacto de las variaciones lgicas
registrando externamente la lgica, leyndola, y utili.ando un intrprete.
Diseo relexivo o de meta!nivel: 3e protege al sistema del impacto de la lgica o variaciones del
cdigo mediante algoritmos reflexivos que utili.an introspeccin y servicios de metalenguaje 9Ej6
:et"od.invo;e<.
"rincipio de sustituci#n de $is%ov &"S$': El soft=are 9mtodos, clases, ...< que "ace referencia a un
tipo > 9alguna interfa. o superclase abstracta< deber, trabajar correctamente o como se espera con
cualquier implementacin o subclase de > .
Diseo de ocultaci#n de la estructura &no hable con extraos ': $n mtodo solo deber, enviar
mensajes a los siguientes objetos6
El objeto t"is o self-
$n par,metro del mtodo-
$n atributo de t"is-
$n elemento de una coleccin que es un atributo de t"is-
$n objeto creado en el mtodo.
Los objetos directos son !conocidos# del cliente, los objetos indirectos son !extraos#. $n cliente
deber, "ablar solo con conocidos y !evitar "ablar con extraos#.
En una manera m,s general se tiene que !1ada unidad debe "aber limitado solamente conocimiento
sobre otras unidades6 solamente unidades relacionadas ?de cerca? pueden comunicarse con la
unidad actual#.
Ventaja! de Variacione! Prote%ida!$
3e aaden f,cilmente las extensiones que se necesitan para nuevas variaciones-
3e pueden introducir nuevas implementaciones sin afectar a los clientes-
3e reduce el acoplamiento-
7uede disminuirse el impacto o coste de los cambios.
Indireccin$
La indireccin es un patrn grasp que se utili.a cuando se tienen diferentes mdulos independientes
entre si, para los cuales se quiere lograr un menor acoplamiento "aciendo que ellos no tengan el menor
conocimiento de la existencia del otro facilitando la reutili.acin de cdigo 9gracias a la independencia
intermodular< y aumentando la facilidad de ampliar la aplicacin.
La solucin consiste en crear otro modulo que se encargue de crear la comunicacin entre estos los
mdulos mencionados anteriormente, este deber, conocer las funcionalidades que cada modulo desea
comunicar al otro.
Ejemplo$
En una aplicacin se tienen dos mdulos, uno se encarga de calcular cuanto se debe pagar por un
servicio incluyendo el impuesto actual y el otro es quien ingresa la informacin en una base de datos.
7ara solucionar este problema es necesario crear una clase llamada en este caso 1omunicador que
cono.ca los otros mdulos y que integre los mtodos encargados de calcular el pago e ingresar la
informacin en una base de datos de las clases 1alculo y @ac"ada% respectivamente.
1on esto ganamos la posibilidad de reutili.acin del cdigo de las clases 1alculo y @ac"ada% adem,s
de disminuir el acoplamiento entre estas dos clases.
Ejemplo
public cla!! CalcularPa%o
&
double impue!to'
CalcularPa%o(double impue!to)
&
t*i!+impue!to , impue!to'
-
public double calcular(int precio)
&
double . , (double)precio'
return ./(. 0 impue!to)'
-
-
import ja1a.+!2in%+0'
public cla!! Imprimir
&
Strin% !tr'
public Imprimir(Strin% !tr)
&
t*i!+!tr , !tr'
-
public 1oid mo!trar()
&
3OptionPane+!*o2e!!a%eDialo%(null4 !tr)'
-
-
public cla!! Indireccion
&
CalcularPa%o calc'
Imprimir imp'
int totalPa%o'
Indireccion()
&
double impue!to , 5+67'
int precioini , 85555'
CalcularPa%o p , ne2 CalcularPa%o(impue!to)'
double preciofin , p+calcular(precioini)'
Imprimir imp , ne2 Imprimir
(9:n articulo con un precio$ 9/precioini/9 con impue!to de 9/impue!to/9
finalmente cue!ta$ 9/preciofin)'
imp+mo!trar()'
-
public !tatic 1oid main(Strin% a;<)
&
Indireccion ind , ne2 Indireccion()'
-
-
"iblio%rafia
"ttp6AAtranslate.google.comAtranslate2
"lBesCslBenCuB"ttp6AA===.ccs.neu.eduA"omeAlieberALo."tmlCprevBAsearc"DE@qDEDFGFFLa=
DF%ofDF%emeterDFGFFDFH"lDEesDFHlrDEDFHsaDEI
"ttp6AAlsi.ugr.esAJig&AisooAldemt."tml