Bridge (padrón de deseño): Diferenzas entre revisións

Contido eliminado Contido engadido
m Bot: Substitución da categoría "Patróns de deseño" pola categoría "Padróns de deseño"; cambios estética
m Arranxos varios, replaced: patrón → padrón (19)
Liña 1:
O patrónpadrón '''Ponte''', tamén coñecido como Bridge, é un [[Patrónpadrón de deseño|patrónpadrón]], pertencente á categoría de patrónspadróns estruturais, empregado na enxeñaría do software. Con él pretendese separar unha abstracción da súa implementación, desta forma poderanse empregar implementacións alternativas.
 
O patrónpadrón Ponte pode ser moi útil cando as implementacións varian a miúdo. Nese caso, as características da programación orientada a obxetos, tórnanse moi útiles, podendo facer cambios no código cun mínimo coñecemento previo do programa.
 
== Obxectivos ==
Liña 8:
 
== Aplicabilidade ==
Podemos empregar o patrónpadrón Ponte cando:
* Queremos evitar unha ligazón permanente entre a abstracción e a súa implementación, podendo ser debido a que a implementación debe ser seleccionada ou cambiada en tempo de execución.
* Tanto as abstracción coma as súas implementación deben ser extensibles por medio de subclases. Neste caso, o patrónpadrón Ponte permite combinar abstracción e implementación diferentes e estendelas independentemente.
* Os cambios na implementación dunha abstracción non deben impactar nos clientes,o seu código non ten que ser recompilado.
* Queremos ocultar a implementación dunha abstracción completamente ós clientes.
Liña 23:
== Consecuencias ==
* Desacoplamento do obxecto interface e implementación: una implementación non é limitada permanentemente a unha [[interface]]. A implementación dunha abstracción pode configurarse en tempo de execución. Ademais, un obxecto, ten a posibilidade de cambiar a súa implementación en tempo de execución. Desacopla Abstraction e Implementor tamén elimina as dependencias sobre a implementación en tempo de compilación. Cambiar unha clase de implementación non require recompilar a clase Abstraction nin os seus clientes. Esta propiedade é esencial cando hai que asegurar a compatibilidade binaria entre diferentes versións dunha biblioteca de clases, fomentando as capas, que nos leven a un nivel mellor estruturado.
 
* Mellorar a estensibilidade: Pódese estender as xerarquías de abstracción e implementación de forma independente.
 
== Estrutura ==
O cliente non quere lidiar cos detalles dependentes da plataforma. O patrónpadrón Ponte encapsula estas complexidades tras unha capa abstracta.
 
Ponte enfatiza identificar e desacoplar a abstracción de interface da abstracción da implementación.
Liña 33 ⟶ 32:
 
== Implementación ==
* Só un Implementador: en situación onde existe só unha implementación, non é preciso crear una clase Implementor abstracta, sendo este, un caso especial do patrónpadrón no que hai unha relación un-a-un entre Abstraction e Implementor. Non obstante, esta separación é moi útil cando un cambio na implementación dunha clase non debe afectar os seus clientes.
* Implemementador: Sendo esta unha das principais diferenzas có patrónpadrón estratexia, se a abstracción coñece a xerarquía de implementadores pode crear o implementador no construtor, podendo decidir cal instanciar dependendo dos parámetros do construtor. O inconveniente ven dado pola dependencia da xerarquía, se aparece un novo teremos que modificar a abstracción.
 
* Implemementador: Sendo esta unha das principais diferenzas có patrón estratexia, se a abstracción coñece a xerarquía de implementadores pode crear o implementador no construtor, podendo decidir cal instanciar dependendo dos parámetros do construtor. O inconveniente ven dado pola dependencia da xerarquía, se aparece un novo teremos que modificar a abstracción.
 
Outra aproximación é delegar noutro obxecto (singleton), este encargarase de proporciona o implementador concreto da abstracción.
 
* Compartir implementadores.
 
* Empregando herdanza múltiple.
 
== Ponte con outros patrónspadróns ==
* [[Adaptador]] fai que as cousas funcionen despois de ser deseñadas, Ponte fai que as cousas funcionen antes de ser deseñadas.
* Ponte é deseñado para permitir que a abstracción e a implementación varíen de forma independente.Adaptador é deseñado para que clases non relacionadas traballen xuntas.
* [[State (patrónpadrón de deseño)|Estado]], [[Strategy (patrónpadrón de deseño)|Estratexia]], [[Bridge (patrónpadrón de deseño)|Ponte]] (e algúns casos de Adaptador) teñen solucións estruturais semellantes. Diferéncianse na intención, resolven diferentes problemas.A estrutura de Estado e de Ponte é idéntica (excepto que Ponte admite xerarquías de herdanza envolventes, mentres que Estado só permite unha). Os dous patrónspadróns usan a mesma estrutura para resolver diferentes problemas: Estado permite cambiar o comportamento dun obxecto o cambiar o seu estado, mentres que Ponte pretende desacoplar a abstracción da súa implementación, podendo variar estas dúas de forma independiente.
* Se a clase interface delega a creación a clase implementación, entón o deseño usualmente emprega o patrónpadrón Fábrica Abstracta para crear os obxectos implementación.
* Ponte semella o patrónpadrón adaptador , pero mentres que o patrónpadrón Adaptador intenta que as interfaces dunha ou mais clases sexa a mesma que para unha clase particular, Ponte está deseñado para separar as clases interfaces da súa implementación, desta forma poder variar e reemplazar as súas implementacions sen cambiar o código cliente.
 
== Exemplo ==
Liña 102 ⟶ 99:
<source lang="java">
/**
* Clase Main do exemplo do patrónpadrón Ponte (Bridge)
*
*/
Liña 161 ⟶ 158:
_mem.set(i.intValue(), dato);
}
 
 
private Vector<String> _mem;
Liña 206 ⟶ 202:
_mem.put(i, dato);
}
 
 
private HashMap<Integer, String> _mem;