Qual Design Pattern usar...

[Bruno Augusto 417]

Cenário

 

Uma Factory Class recebe uma string como parâmetro e instancia outra de acordo com o dito parâmetro, passando como argumento para essa classe instanciada, um array de opções.

 

Ex:

 

$factory = Factory::factory( 'A', $options );
$factory = Factory::factory( 'B', $options );

Isso retorna uma instancia da classe A ou B.

 

Em qualquer uma dessas classes, tenho métodos genéricos, como por exemplo, add() que adiciona alguma coisa, a exemplo, um arquivo.

 

As definições do que será adicionado e como será adicionado vêm de uma classe instanciada em um dos índices do array de opções passados.

 

Ex:

 

$factory = Factory::factory( 'A', array( 'adapter' => new MyAdapter() ) );
$factory -> add( 'Foo' );

// Na classe A...

private $adapter;

public function __construct( array $options = array() ) {

   if( isset( $options['adapter'] ) ) {
       $this -> adapter = $options['adapter'];
   }
}

public function add( $name ) {

   file_put_contents( $name . '.' . $this -> adapter -> getExtension() );
}

// No adaptador TXT, por exemplo...

const EXTENSION = 'txt';

public function getExtension() {
   return self::EXTENSION;
}

E essa situação poderia ser "reciclada" para tantos adaptadores quantos eu queira criar.

 

Num adaptador PHP, o método getExtension() retornaria php.

Num adaptador DOC, o método getExtension() retornaria doc.

Num adaptador PDF, o método getExtension() retornaria pdf.

Num adaptador JPG, o método getExtension() retornaria jpg.

 

Só ilustrando, pois não pretendo fazer só isso e nem desse jeito.

 

Isso é um Design Pattern? É quase um? Tem nome? Pode ser melhorado? Enfim...

[João Batista Neto 448]

,

 

A primeira vista, você está tentando usar um Parameterized Factory Method, mas qual o contexto onde você está utilizando isso ?

 

Pergunto porque ficará mais fácil te ajudar se você explicar exatamente o que você está tentando fazer.

[Bruno Augusto 417]

O contexto é bem o pressuposto pelo tópico. Uma classe constrói N outras, pelo parâmetro como dito. Essa outra construída possui métodos que trabalham com recursos provenientes de um adaptador.

 

Aquilo que a classe construída fará, dependerá do adaptador. Mas podem ser infinitos adaptadores criados por mim ou por terceiros e instanciado, atualmente, no array de parâmetros.

[João Batista Neto 448]

Certo, mas você não tem um Adapter ai, um Adapter serve exatamente para isso, adaptar um objeto de uma interface à outra interface incompatível, por exemplo:

 

Você tem uma interface Target:

interface Target {
public function testando();
}

 

E uma implementação:

class Tipo1 implements Target {
public function testando(){
	var_dump( __METHOD__ );
}
}

 

Ai, sua classe Teste usa isso normalmente:

class Teste {
public function testar( Target $teste ){
	$teste->testando();
}
}

$obj = new Teste();
$target = new Tipo1();

$obj->testar( $target );

 

Só que um dia, você se viu em uma situação onde você possui um objeto de um outro tipo para usar com seu objeto Teste:

interface Adaptee {
public function testar();
}

class Tipo2 implements Adaptee {
public function testar(){
	var_dump( __METHOD__ );
}
}

 

Você não pode passar um Tipo2 para para o Teste porque ele espera um Target, nesse caso, você utiliza um Adapter:

class Adapter implements Target {
private $adaptee;

public function __construct( Adaptee $adaptee ){
	$this->adaptee = $adaptee;
}

public function testando(){
	$this->adaptee->testar();
}
}

 

Dessa forma, seu Teste poderá usar o Tipo2:

$obj = new Teste();
$adaptee = new Tipo2();

$obj->testar( new Adapter( $adaptee ) );

[Bruno Augusto 417]

Vou tentar expor esse fato fictício de forma menos fictícia, abordando um contexto completo para construir um cenário detalhado.

 

Parte I - Construção do Objeto

 

Método factory da classe FileSystem recebe dois parâmetros, um do tipo string e outro do array.

 

Realiza as rotinas de verificação necessárias, prepara o nome final da classe a ser instanciada e cria o objeto, retornando-o.

 

Parte II - O Objeto Construído

 

Supondo que o objeto construído seja uma classe File que no contexto FileSystem manipula arquivos, criando, removendo, renomeando, copiando...

 

Tomemos como base a ação de criar, ilustrada pelo método create() que recebe dois parâmetros do tipo string: um para o path pai, isto é, onde o arquivo será criado e outro name com o nome do arquivo.

 

Mas que tipo de arquivo será criado? Um TXT, PHP, PDF, DOC, XLS... Enfim, são N possibilidades.

 

Tais possibilidades devem ser tratadas individualmente por uma única classe, classes essas que fornecerão informações para a classe construída pelo Factory.

 

Mas que tipo de informações?

 

Voltemos com o exemplo das extensões de arquivo originalmente proposta. Mesmo que um tipo de arquivo possua mais de uma extensão, normalmente apenas uma "manda", sendo a mais importante:

 

PHP => php3, php4, php

JPG => jpg, jpeg

 

O anterior e incorretamente por mim chamado adaptador informa, através do método getExtension(), qual a extensão do arquivo a ser criado pelo métod create() que existe apenas na classe File (não nas classes que manipulam os tipos de arquivo a ser criado).

 

Esse é o novo antigo cenário, mais detalhado porém ainda fictício.

[lucasmartins 6]

Isso é um Design Pattern? É quase um? Tem nome? Pode ser melhorado? Enfim...

 

Veja, olhando rapidamente (pois estou meio apressado pra buscar minha namorada agora ), eu vejo a utilização de dois Design Pattern: um é o Iterator e outro Abstract Factory. Por tanto, não vejo essa implementação como sendo um Design Pattern específico, mas sendo um conjunto, se pode ser melhorado... hmmm, tenho que olhar direito depois, o João sabe te dizer melhor do que eu, muito melhor =P, e espero que ele acesse aqui mais tarde pois também estou curioso... =)

 

Abraços,

Lucas Martins