Análise de Estrutura

[Daniel Ribeiro 4]

Olá pessoal!

 

Tenho estudado ultimamente alguns padrões de projeto para o desenvolvimento de meu framework pessoal.

 

Até agora, terminei a camada de abstração para as instruções SQL, onde utilizei o padrão Query Object.

 

Com isso não encontrei muitas dificuldades.

 

Minhas dúvidas encontram-se realmente na parte dos design patterns abstraem as camadas da aplicação em seus devidos lugares, como o model (persistência, regras de negócio e active records).

 

Por enquanto pensei na seguinte estrutura de exemplo:

 

- Entidade.action.php (Esta camada conversa diretamente com o controller);

- Entidade.bo.php (Nesta camada encotram-se as regras de negócio para a próxima camada, que seria de persistência);

- Entidade.ar.php (Aqui estará a persistência por si só. Esta camada geralmente será filha da Base.ar.php, que conterá as operações básicas de CRUD com o banco de dados);

 

Seguem os exemplos:

 

Cliente.action.php

class ClienteAction extends BaseAction {

private $entidade;

public function __construct() {
	$this->entidade = 'tb_cliente';
}

public function doCadastroCliente($dados) {
	if(is_array($dados)) {
	$bo = new ClienteBO();
	return $bo->doCadastroCliente($dados);
	}
}

}

 

Cliente.bo.php

class ClienteBO extends BaseBO {

public function doCadastroCliente($dados) {
	$ar = new ClienteAR();
	foreach($dados as $coluna => $valor) {
	if($valor == 'teste') {
	throw new Exception('morreu!');
	} else {
	return $ar->store($dados);
	}
	}
}

}

 

Cliente.ar.php

class ClienteAR extends BaseAR {

const ENTIDADE = 'tb_cliente';

public function store($dados) {
	if(is_array($dados)) {
	return BaseAR::store($dados, self::ENTIDADE);
	}
}

}

 

O que acham desta estrutura?

[João Batista Neto 448]

Até agora, terminei a camada de abstração para as instruções SQL, onde utilizei o padrão Query Object.

 

Esse é um padrão de domínio específico, muito legal, principalmente se for utilizado o padrão GoF chamado Interpreter. Caso não o tenha utilizado, talvez tenha interesse em acompanhar esse fórum, estarei publicando em breve um exemplo de Query Object utilizando Interpreter.

 

- Entidade.action.php (Esta camada conversa diretamente com o controller);

- Entidade.bo.php (Nesta camada encotram-se as regras de negócio para a próxima camada, que seria de persistência);

- Entidade.ar.php (Aqui estará a persistência por si só. Esta camada geralmente será filha da Base.ar.php, que conterá as operações básicas de CRUD com o banco de dados);

 

O que acham desta estrutura?

 

Veja, herança de classe define a implementação de um objeto como a implementação de outro objeto, ou seja, você compartilha código de um objeto em outro. Isso é importante até certo ponto, porém, se não utilizado adequadamente, viola o encapsulamento.

 

Procure estudar os padrões Chain Of Responsibility para a Controller e Composite para a View e procure trabalhar focado na interface.

 

Outro ponto importante no fragmento que você postou é a ausência de padrão, você está programando literalmente para uma implementação e sua aplicação irá falhar se a implementação for diferente do esperado.

 

Os métodos de seus objetos recebem qualquer argumento como parâmetro e têm que adivinhar, em tempo de execução, o que tal parâmetro é na verdade e, após essa adivinhação, trabalhar com o valor segundo regras pré-definidas. Esse tipo de implementação inevitavelmente gerará duplicação de código e, uma hora ou outra, quando você precisar fazer uma manutenção, adaptação ou ter que escalar sua aplicação de qualquer forma e ter que "injetar" uma funcionalidade ou outra a um objeto, você poderá esquecer algum fragmento duplicado e ganhará de brinde um bug difícil de detectar.

 

Se você estiver escrevendo esse framework pensando em PHP 5.3, atente-se aos namespaces, além de melhorar a organização do código, permite que o Controller resolva em tempo de execução o objeto da Model e da View que deve instanciar, mesmo não conhecendo a localização física dos mesmos.

[Daniel Ribeiro 4]

Entendi boa parte do seu discurso João, exceto pela parte em que fala que estou programando para uma implementação e não para uma aplicação.

 

Poderia explicar melhor?

 

E com relação ao que falaste sobre repetição do código, também ficou um pouco confuso.

 

Como assim os meus métodos recebem qualquer parâmetro? Não entendi.

 

E sobre namespaces, nunca utilizei, nem sei como começar.

 

Poderia me dar uma luz?

 

Obrigado pela atenção.

[lucasmartins 6]

Entendi boa parte do seu discurso João, exceto pela parte em que fala que estou programando para uma implementação e não para uma aplicação.

 

E com relação ao que falaste sobre repetição do código, também ficou um pouco confuso.

 

Não é programando para uma implementação e não para uma aplicação, pois de qualquer jeito você está programando uma aplicação. Mas acho que o que ele quis dizer é que você precisa de mais polimorfia e seus códigos tendem a se repetir um pouco, perceberias isso mais para frente se continuar fazer dessa forma, como na classe ClienteAR.

 

Você pode dar uma olhadinha nesses tutoriais que o João está montando: http://forum.imaster...tado-a-objetos/

 

Como assim os meus métodos recebem qualquer parâmetro? Não entendi.

 

 

 

Você pode utilizar Type Hinting para corrigir esse problema:

http://br2.php.net/m...typehinting.php

 

 

E sobre namespaces, nunca utilizei, nem sei como começar.

 

Poderia me dar uma luz?

 

Obrigado pela atenção.

 

Um belo começo é entrar e fuçar nessa página: http://br2.php.net/m....namespaces.php

 

Não sei se você já programou em Java, mas é parecido com os packages do java. Namespaces servem para te ajudar a organizar suas classes, evitar alguma sobreposição de classes quando se usa um (ou mais de um) framework, evitar nomes longos em classes, etc...

 

Abraços, espero ter dado uma luz mínima pelo menos ;P

[Daniel Ribeiro 4]

Não tinha necessidade de ressucitar este tópico.

 

Já venho trabalhando com orientação a objetos em um nível bem superior e com bastante frequência.

 

Mas mesmo assim, obrigado pelas dicas.