Bridge Atende?

Programação Arquitetura
#1

Tenho uma massa de objetos na memória e preciso filtra-los. Atualmente tenho três condições:

X,Y,Z

eu estava implementando assim:

find();  //Essa assinatura para trazer todos os objetos
find(x);
find(y);
find(z);
find(x,y);
find(y,z);
find(z,x);
find(x,y,z);

Depois surgiu uma duvida: E se o escopo mudar aumentando o números de condições… A quantidade de métodos irá crescer exponencialmente…

Um pattern que me veio a cabeça foi o bridge, mas além de não saber se ele atende ou se existe outros que sejam melhor recomedados, também não sei implementar nenhum :lol:

Alguém se habilita?

#2

Hmm, será que o pattern de decorator não seria melhor?
[/code]

#3

Pattern!? Isso se resolve com um Object[], ou melhor ainda, Criteria[]! :smiley:

#4

ou se nao esperar pela versão 1.5 do java

[quote]Varargs:
Quando criamos um método que leva um número variável de parâmetros normalmente utilizamos arrays (é o caso do método main, por exemplo). Com o uso de Varargs não é mais necessário utilizar apenas arrays. Veja como ficaria a declaração de um método que recebe um número variável de argumentos sem utilizar Varargs:

Agora veja como fica o mesmo trecho com o uso de Varargs:

[/quote]

Isso é um trecho da pagina http://www.repositoriojava.com.br que fala sobre as novidades do java 1.5

é apenas uma brincadeira mas é interessante ver o que podemos esperar da nova versão…

#5

O legal é que não existe milagre!
Seu eu uso um Object[] dentro do metódo eu tenho que fazer varios “ifs”…

Bom de qualquer jeito … se tiver mudança de escopo tem impacto!!!

A unica coisa que eu fiz foi usar reflexão para escolher o método que deve ser chamado:

[code]
Object oParametros[] = par.toArray();
Class cParametros[] = new Class[cla.size()];

				Iterator it = cla.iterator();
				int count = 0;
				while(it.hasNext()){
					cParametros[count++] = (Class) it.next();
				}
				
				
				Class c = this.getClass();


				try {
					Method m;
					m = c.getMethod("find", cParametros);
					m.invoke(this,oParametros);
				} catch (NoSuchMethodException e) {
					e.printStackTrace();
				} catch (SecurityException e) {
					e.printStackTrace();
				} catch (IllegalArgumentException e1) {
					e1.printStackTrace();
				} catch (IllegalAccessException e1) {
					e1.printStackTrace();
				} catch (InvocationTargetException e1) {
					e1.printStackTrace();
				}[/code]
#6

Ainda nao entendi seu problema… pq fazer varios ifs?

#7

Eh cara eu expliquei mal mesmo!

Seguinte:

1º - Eu queria evitar o produto cartesiano toda vez que uma nova condição fosse adicionada.
Caso eu utilize o que você sugeriu dentro desse método eu teria que verificar na mão a combinação de parâmetros, já que o processamento deve ser alterado de acordo com os parâmetros…

2º - Como optei por ter vários métodos um outro trabalho era verificar qual o método deveria ser chamado.
Foi pra isso que eu usei reflexão:

find(BigDecimal);
find(String);
find(Date);
find(BigDecimal,String);
find(BigDecimal,Date);
find(String,Date);
find(BigDecimal,String,Date);

eu teria que fazer isso:

if(BigDecimal != null && String == null && Date  == null)
   find(BigDecimal);
if(BigDecimal != null && String != null && Date  == null)
  find(BigDecimal,String);
if(BigDecimal != null && String != null && Date  != null)
 find(BigDecimal,String,Date);
.
.
.

Aquele código que postei diz respeito a essa segunda situação…

Voltando ao assunto…

O pouco que eu li sobre o brigde me diz que a utilidade dele era pra coisas como no exemplo seguinte:

Supondo que você tenho que escrever classes que desenhem formas geométricas na tela:

Ponto;
Circulo;
Retangulo;

Só que pra cada Sistema Operacional o desenho é feito de uma maneira diferente:

Windows;
Linux;
Mac;

Então temos:

PontoWindows
PontoLinux
PontoMac

RetanguloWindows
RetanguloLinux
RetanguloMac

CirculoWindows
CirculoLinux
CirculoMac

Se depois eu tivesse que adicionar um novo sistema operacional eu teria que criar classes Ponto,Circulo,Retangulo…

Pelo que o vi e o próprio nome diz ele faria uma ponte entre estes dois universos…

Então pensei se seria possível utilizar essa mesma lógica para os métodos. Vejam a semelhança:

find(X)
find(Y)
find(Z)

find(X,Y)
find(X,Z)
find(Y,Z)

find(X,Y,Z)

O usuário sonha que quer incluir o K na jogada…

find(X)
find(Y)
find(Z)
find(K)

find(X,Y)
find(X,Z)
find(X,K)
find(Y,Z)
find(Y,K)
find(Z,K)

find(X,Y,Z)
find(X,Y,K)
find(Y,Z,K)

find(X,Y,Z,K)

Entenderam o que eu to querendo evitar.

Desculpa aí se eu to complicando as coisas, mas eu postei isso aqui justamente por que eu sabia que alguém tem uma idéia muito mais simples e eficiente :lol:

#8

ta, aproveitando seu exemplo, entao…

public interface Pixel { Color getColor(); int getX(); int getY(); }

public class PixelWindows implements Pixel { // ... }

public class PixelLinux implements Pixel { // ... }

public class PixelMacOS implements Pixel { // ... }

public void draw(Pixel p) { Color c = p.getColor(); int x = p.getX(), y = p.getY(); paint(x,y,c); }

Nao vejo nenhum pattern aqui… so o bom e velho uso de interfaces pra separar implementacao do contrato que os objetos tem que cumprir :wink:

#9

não é bem isso cv! me reponda: se você tivesse 10 O/S e 10 Formas geometricas, quantas classes você teria?

#10