[Resolvido] Interfaces...

[Bruno Augusto 417]

Cara eu sei o que é OOP e o que são Padrões de Projeto, é que meu cerébro às vezes trabalha de uma forma muito cabulosa.

 

Esse assunto já passou :thumbsup:

 

Você disse que eu não implementei corretamente e citou sua própria falta de entendimento com os exemplos em C++ e Java.

 

Eu tenho o MESMO problema. Se eu implementei o padrão de forma errada, foi porque não entendi lhufas do que o Martin exemplificou no livro dele.

 

Se pra você os padrões referentes ao banco são mamão-com-açúcar, deixa eu pegar uma colher, então.

 

Mesmo que você não goste, ou que pessoalmente ache que estoiu batendo na mesma tecla várias e várias vezes, peço uma colher de chá, explica melhor ONDE eu errei para que eu possa aprender com os meus erros e não cometê-los mais.

[Henrique Barcelos 290]

você leu e entendeu o que eu falei no post #27?

 

ok, acho q nao me fiz ser entendido, nao eh so ler, primeiro tem de enteder o q eh e o q faz um padrao de projeto:

 

ele resolve um problema, ae eu t pergunto: qual problema?

 

ele eh usado eh determinado contexto: ae eu t pergunto em qual contexto?

 

e ele tem uma solucao, como você implementa... por exemplo em AS nao ha construtor privado, nao tem como fazer, mas tem como fazer um singleton? sim tem, nao adianta pensar em programacao se nao pensar na tteoria, eu aprendi OO vendo o mundo real se relacionar, tente ler o padrao tentando implementa-lo no mundo real, e depois passe isto para a programacao...sabe o exemplo de um array: o conceito de lista? quando alguem me pede pra dar aula de programacao, eu ensino array assim: lista de supermercado, eu nao entendi a teoria? entao eu inverto a abstracao, nao passo o conceito apra a programaco, eu passo para o mundo real, entendi? sim? entao eu passo para a programacao....mas sempre com os conceitos mais basicos de cada um: OO e DP (design pattern)

[Henrique Barcelos 290]

Não acho que aqui seja o problema de entender o conceito ou a definição do que são design patterns, o problema é aplicá-los de maneira eficaz e eficiente, o que é a parte mais difícil.

 

Você disse que eu não implementei corretamente e citou sua própria falta de entendimento com os exemplos em C++ e Java.

Eu tenho o MESMO problema. Se eu implementei o padrão de forma errada, foi porque não entendi lhufas do que o Martin exemplificou no livro dele.

E olha que C++ e Java tem sintaxe muito parecida com PHP, imagina eu uma vez aprendendo sobre ORM num artigo sobre Python (não, eu não sei Python, ainda)...

 

Eu realmente não entendo a mania desses autores, tão referenciados no mundo dos design patterns, tem de nos darem exemplos completamente abstratos.

É tão difícil assim aplicar esse tipo de coisa no mundo real? Pelo visto é.

 

O melhor material de consulta encontrar exemplos práticos de aplicação de design patterns é o código-fonte de frameworks, seja Spring, Django, Rails, Zend, Symphony, ou qualquer outro, é meio complicado você dizer que é um framework se ele não implementa alguns pares de padrões.

 

eu acho q o problema seja entender sim bem os desing patterns, você saberia construir uma casa, pelo menos levantar uma parede sem saber o q usar, que materiais usar:cimento e tijolo? isso tb eh teoria, e em q ordem os coloca? isso tb eh teoria, você precisa add algo a mais no cimento, o q? isso tb eh teoria....para andar de bicicleta primeiro você aprende, sem pedalar, sem anda, q você tem q se equilibrar...mas pra isto você tem q empurrar, estar numacerta velocidade, e pedalar, ae você se equilibra, isto eh teoria, nao se percebe mas esta teoria vai ara o subconsciente, por isso nao a percebe...mas primeiro você te de ter colunas fixas, firmes e solidas, para so entao depois colocar-lhe paredes e outros penduricalhos...

 

mas ae Bruno, algo q t pergunto: qual problema você ker resolver? em q contexto? nao saia lendo tudo q eh teoria q você vai confundir td (isso acontece comigo), apenas foque no q realmente importa...

[Bruno Augusto 417]

No momento não quero resolver problema nenhum, quero criar um conjunto sólido a ponto de poder ser utilizado automaticamente (essa parte em particular está feita) por qualquer Model, seja uma Entidade ou não, com qualquer banco de dados e da forma mais simples e transparente possível.

 

No momento não quero resolver problema nenhum, quero criar um conjunto sólido a ponto de poder ser utilizado automaticamente (essa parte em particular está feita) por qualquer Model, seja uma Entidade ou não, com qualquer banco de dados e da forma mais simples e transparente possível.

perceba entao q você tem 3 pontos a verificar, logo um unico padrao nao sera utilizado...ja pensou em usar o diagrama de sequencia ? de repente ele pode t fornecer pistas do melhor padroa a utilizar...eu utilizaria um strategy pra selecionar o tipo de banco, o singleton pra conectar, e qq model / entidade usar o active record em conjunto o lazy initialization....se bem q o active record nao permite muito relacionamento neh...entao o data row, ou o table data gatway seria melhor...mas lembr-se o model eh a parte mais alta da abstracao com o db, pq você um objeto pra conectar e o model esra responsavel pela regra de engocio...

[Henrique Barcelos 290]

No momento não quero resolver problema nenhum, quero criar um conjunto sólido a ponto de poder ser utilizado automaticamente (essa parte em particular está feita) por qualquer Model, seja uma Entidade ou não, com qualquer banco de dados e da forma mais simples e transparente possível.

 

Quer transparência maior?

$newsGtw = new Db_Table('news');
$news = $newsGtw->getById((int) $_GET['id']); // busca uma notícia por ID
$newsPictures = $news->findDependentRowset('news_picture'); // Busca as imagens cadastradas para aquela notícia.

$text = $news->get('text');
$news->set('title', htmlentitydecode($text)); // O texto da notícia normalmente contém HTML

 

Pra 'ignorar' totalmente a existência de um adapter, em Db_Table existe uma propriedade estática chamada defaultAdapter. Essa propriedade é setada no bootstrapping provendo um adapter padrão a todos os objetos Db_Table. Se eu não passar nenhum adapter para o construtor de Db_Table, ele utilizará esse padrão, caso eu queira me comunicar com outro servidor que não o padrão, basta informar uma instância de um Adapter.

 

E uma coisa que eu reparei nesse meio tempo é que ActiveRecord funciona melhor para programas stateful, o que não é o caso das nossa aplicações sobre o protocolo HTTP, que é stateless. Não faz sentido então manter um ActiveRecord, ele vai "morrer" no fim da execução.

 

Novamente, quero destacar esta parte do post #21:

Veja seu exemplo:

class User extends AbstractMapper {

   protected $_table = 'users';

   protected $id;
   protected $username;
   protected $password;

   public function findUserByName() {}

   public function findUserById() {}
}

No sentido de que o objeto que fizer uso de um objeto User, precisa conhecer parte de sua implementação.

findUserByName é um método que vai buscar o usuário pelo seu nome, logo, para eu utilizá-lo, eu preciso saber que um usuário tem um nome.

 

Você também teria que criar métodos setters e getters para as propriedades $id, $username, etc.

Na hora de utilizar, você faz:

$user = new User();
$password = $user->getPassword();

Novamente, você precisa conhecer a implementação.

 

Diagrama de classes simplificado:

[JCMais 75]

Bruno, dá olhada no código do DBAL do Doctrine, pode clarear algumas coisas. Principalmente a interface Driver e suas implementações.

https://github.com/doctrine/dbal/tree/master/lib/Doctrine/DBAL

 

Ao meu ver a melhor forma para entender é vendo exemplos reais, do que exemplos com analogias sem nexo.

[Bruno Augusto 417]

Pois é eu até pensei no Doctrine, tanto no manual/quickstart como o Github e além do básico (Driver/Adapter, Statement...), o que consegui "pegar" foi a questão do mapeamento, via comentário de classe ou um tal de YAML.

 

Mas na estrutura deles é usado um padrão Repository que não chega a ser complicada mas, pra mim, hoje é desnecessário e um tal de Unit of Work, numa classe própria até, e ele é quem realmente executa as ações de CRUD, especificadas/criadas no EntityManager deles.

[JCMais 75]

Mas na estrutura deles é usado um padrão Repository que não chega a ser complicada mas, pra mim, hoje é desnecessário e um tal de Unit of Work, numa classe própria até, e ele é quem realmente executa as ações de CRUD, especificadas/criadas no EntityManager deles.

 

Isso aí já é o ORM, o DBAL (Database Abstraction Layer) é um projeto separado, sem quaisquer dependências para com o ORM (Object Relational Mapper), são projetos BEM diferentes.

 

ver exemplos reais eh como tentar criar uma escultura de barro, cozendo ele sem retirar as pedras...você sabe q tem q tirar as pedras? nao, nao estudou a teoria...e as pedras dentro da argila so vai fazer sua escultura rachar, conhecimento eh para os conhecedores, as analogias para os sabios...você pode at usar uma bicicleta pra correr, mas jamais vai faze-la correr com mais velocidade e agilidade sem conhecer a profundo seu mecanismo, e digo, profundo, o q vai alen da corrente...

[Henrique Barcelos 290]

Olha, estou dando uma olhada aqui no DBAL e acho que vai acabar confundindo mais. Tem algumas "gorduras" bem desnecessárias para a maioria dos mortais ali.

[JCMais 75]

Henrique, ali só é interessante analisar as implementações das interfaces Driver, Statement e Connection, o resto seria apenas para confundir.

 

Henrique, ali só é interessante analisar as implementações das interfaces Driver, Statement e Connection, o resto seria apenas para confundir.

exatamente como eu disse acima, nos tre pontos q você teria q focar...

 

Olha, estou dando uma olhada aqui no DBAL e acho que vai acabar confundindo mais. Tem algumas "gorduras" bem desnecessárias para a maioria dos mortais ali.

concordo...por isso eu prefiro a teoria pura e simples do autor....

[Bruno Augusto 417]

Henrique, pode postar um exemplo de uso para insert's e update's da forma como fez, com Table Row?

[Henrique Barcelos 290]

Normalmente você vai utilizar isso quando numa mesma requisição você precisa ler e atualizar dados.

Bom, um exemplo prático.

Vamos imaginar que você tem um sistema que necessita de autenticação. Além disso, você tem um campo TIMESTAMP chamado `last_access` que armazena o timestamp do último acesso de um determinado usuário.

 

No método que faz a autenticação.

 

public function auth(array $context){
$username = isset($context['username']) ? (int) $context['username'] : null;
$password = isset($context['password']) ? md5($context['password']) : null;

$userData = $this->tables['user']->getById($id);
if($userData === null){
	$result = $this->createResult();
   	$result->registerError('Usuário e/ou senha inválidos');
	return $result;
}

$currTmstp = strtotime(date('Y-m-d H:i:s'));
$userData->set('last_access', $currTmstp);

try {
	$userData->save();
} catch (Exception $e){
	$result = $this->createResult();
	$result->registerException($e);
   	return $result;
}

return $this->createResult(array('userData' => $userData));
}

[Bruno Augusto 417]

Era bem isso que eu queria confirmar, antes de fazer um UPDATE ou um DELETE, deve-se primeiro fazer um SELECT e só executar tais Statements se o primeiro retornar aquilo que se espera, a instância de Table Row.

 

Certo?

 

Se sim ou se não, isso não é ruim pra performance geral do sistema? Afinal tem-se uma outra query rodando antes...

[Henrique Barcelos 290]

Mas se você quer alterar dados que estão no banco, não deveria buscá-los primeiro?

Para dar UPDATE, quase sempre você busca os dados primeiro, altera o necessário e salva de novo.

 

Quando você exibe um formulário para edição dos dados, previamente você fez uma operação de RETRIVE, não?

 

Não entendi a "perda de performance"...

[Bruno Augusto 417]

Pois é, depois que eu parei, respirei bem fundo e parei para analisar/excluir um registro pude comprovar por mim mesmo que é verdade, sempre antes de atualizar alguma informação, é feito uma busca, quase sempre por ID, para ter algo a usar na cláusula WHERE.

 

A diferença é que, desse jeito, o código fica bem menor e MUITO mais legível.

 

Por hora está resolvido, a batalha agora está rolando noutro tópico.