Ir para conteúdo

POWERED BY:

Arquivado

Este tópico foi arquivado e está fechado para novas respostas.

felipe_zmm

Iniciante em OO

Recommended Posts

Olá a todos,

 

Programo em PHP já há algum tempo, porém procedural e estou querendo me familiarizar com o paradigma OO. Para começar, comprei o livro "PHP - Programando com Orientação a Objetos", do Pablo Dall'Oglio. O livro é bom mas chega um ponto em que o autor se limita a exemplos muito básicos e isso acabou me gerando diversas dúvidas.

 

Se possível, gostaria que os colegas analisassem umas classes que fiz e me tirassem algumas dúvidas.

 

Bom, primeiro de tudo para começar eu resolvi que faria uma classe de Usuários. Comecei colocando as propriedades e métodos getters e setters, além de métodos para login e logout. Mas então achei que deveria separar as duas coisas e criei as seguintes classes:

 

class ControleLogin
    {
        //atributos
        private $_login;
        private $_senha;
        
        //variáveis da classe
        private $_bd;
        private $_tabela = 'usuarios';
        
        public function __destruct()
        {
            if (!is_null($this->_bd))
            {
                $this->_bd = null;
            }
        }
        
        public function validarUsuario($login, $senha)
        {
            $this->_bd = new BD();
            
            $this->_login = $login;
            $this->_senha = $this->gerarHash($senha);
            
            $qry = "SELECT COUNT(*) FROM {$this->_tabela} "
                 . "WHERE usuario = :login AND senha = :senha";
                 
            $stmt = $this->_bd->prepare($qry);
            $stmt->bindParam(':login', $this->_login);
            $stmt->bindParam(':senha', $this->_senha);
            $stmt->execute();
            
            if ($stmt->fetchColumn() == 1)
            {
                $this->gerarSessao();
                
                return true;
            }
            
            return false;
        }
        
        public function logout()
        {
            session_start();
            unset($_SESSION);
            session_destroy();
        }
        
        public function usuarioLogado()
        {
            session_start();
            
            if ((!isset($_SESSION['login'])) || (!isset($_SESSION['validado'])))
            {
                return false;
            }
            
            return true;
        }
class Usuario
    {
        private $_id;
        private $_nome;
        private $_sobrenome;
        private $_email;
        private $_login;
        private $_senha;
        private $_status;
        
        public function getId()
        {
            return $this->_id;
        }
        public function setId($id)
        {
            if ($id > 0)
            {
                $this->_id = abs($id);
            }
        }
        
        public function getNome()
        {
            return $this->_nome;
        }
        public function setNome($nome)
        {
            if (is_string($nome))
            {
                $this->_nome = $nome;
            }
        }

 

A classe Usuario contém apenas getters e setters. A minha primeira dúvida surge aí: As classes ControleLogin e Usuario deveriam ser uma só ? Qual seria a forma mais correta de fazer isso ?

 

Seguindo o livro que citei, criei a classe UsuarioMapper, utilizando o pattern DataMapper apresentando pelo autor:

 

require_once 'BD.class.php';
require_once 'Usuario.class.php';
    
    class UsuarioMapper
    {
        private $_bd;
        private $_tabela = 'usuarios';
        
        public function __construct()
        {
            $this->_bd = new BD();
        }
        
        public function incluir(Usuario $usuario)
        {
            $qry = "INSERT INTO {$this->_tabela}(id, usuario, senha, email, nome, sobrenome, ativo, data_cadastro) "
                 . "VALUES(null, :login, :senha, :email, :nome, :sobrenome, 1, CURDATE())";
            
            try
            {
                $stmt = $this->_bd->prepare($qry);
                $stmt->bindParam(':login', $usuario->getLogin());
                $stmt->bindParam(':senha', $usuario->getSenha());
                $stmt->bindParam(':email', $usuario->getSenha());
                $stmt->bindParam(':nome', $usuario->getNome());
                $stmt->bindParam(':sobrenome', $usuario->getSobrenome());
                $stmt->execute();
                
                $ultimoId = $this->_bd->lastInsertId();
                $usuario->setId($ultimoId);
                
                return true;
            }
            catch (PDOException $e)
            {
                echo $e->getMessage();
                
                return false;
            }     
        }
        
        public function listar()
        {
            $stmt = $this->_bd->query("SELECT id, nome, sobrenome, email,                login FROM {$this->_tabela} ORDER BY nome");
            
            while($res = $stmt->fetch(PDO::FETCH_OBJ))
            {
                $usuario = new Usuario();
                $usuario->setId($res->id);
                $usuario->setNome($res->nome);
                $usuario->setSobrenome($res->sobrenome);
                $usuario->setEmail($res->email);
                $usuario->setLogin($res->login);
                
                $usuarios[] = $usuario;
            }
            
            return $usuarios;
        }
    }

 

Bom, a dúvida que me surgiu neste ponto foi quanto à simplicidade de uso dessas classes. No caso de fazer um Insert, a minha aplicação teria que instanciar a classe Usuario, alterar sua propriedades, depois instanciar a classe UsuarioMapper e persistir os dados. Por algum motivo me parece pouco prático e portanto incorreto, não sei se é apenas impressão pela falta de costume. Eu deveria fazer um class Usuario extends UsuarioMapper para facilitar ? Isso é correto ?

 

Enfim, vou parar por aqui porque acho que já estou abusando da boa vontade de quem ler o tópico. Espero que tenham paciência e agradeço desde já.

Compartilhar este post


Link para o post
Compartilhar em outros sites
Enfim, vou parar por aqui porque acho que já estou abusando da boa vontade de quem ler o tópico. Espero que tenham paciência e agradeço desde já.

Quando a pessoa tem vontade de entender e aprender nós respondemos sem problemas, essa é a ideia do fórum.

 

E o que eu tenho pra falar é simples e rápido.

Não sei se é pq esta iniciando ainda mas senti falta de uma interface, na qual seria o seu Validator.

assim você não teria um método validarUsuario e você teria um validator que poderia validar usuários, administradores, parceiros dentre outas coisas..

 

 

 


A classe Usuario contém apenas getters e setters. A minha primeira dúvida surge aí: As classes ControleLogin e Usuario deveriam ser uma só ? Qual seria a forma mais correta de fazer isso ?

Principio de responsabilidade única, não devem ser a mesma coisa.

Devem ser separadas e segmentadas, cada OBJETO tem uma função dentro do sistema e não cada método tem uma função.

tende?

 

 

 

Eu deveria fazer um class Usuario extends UsuarioMapper para facilitar ? Isso é correto ?

Não conheço o pattern mas pergunte e você mesmo e se responde:

Usuários é pai de UsuárioMapper? tem caracteristicas em comum? tem métodos em comum?

Usuário depende de UsuárioMapper pra funcionar?

Compartilhar este post


Link para o post
Compartilhar em outros sites

Vinícius,

Quanto à interface Validator, acho que é sim pela falta de costume com o paradigma, pois como disse programava procedural e ainda tenho que pegar o hábito de programar de forma mais genérica fazendo com que uma solução se aplique em várias situações.

Sobre o princípio de responsabilidade única, foi por causa dele mesmo que resolvi separar em duas classes. Mas o que me confunde bastante é que quando procuro por exemplos/tutoriais na internet vejo as pessoas fazendo tudo em uma classe só.

 

Já sobre o pattern DataMapper é algo que não tenho segurança suficiente pra responder com certeza. Mas acho que de certa forma o UsuarioMapper faz parte da classe Usuario sim, se estivesse utilizando o pattern ActiveRecord os dois estariam na mesma classe. Porém no livro o autor não estendeu a classe. Ele na verdade quis simplificar demais o exemplo e acabou deixando muitas dúvidas.

 

Mas de uma forma geral, estou no caminho certo ?

Compartilhar este post


Link para o post
Compartilhar em outros sites

até agora 2 conceitos esta sim no caminho certo, ainda faltam mais 3

http://valdemarjr.net/2013/01/02/os-5-principios-de-orientacao-a-objeto-s-o-l-i-d.html

 

mas esta no caminho certo significa que falta uns ajustes ainda.

 

 

  Citar

Mas o que me confunde bastante é que quando procuro por exemplos/tutoriais na internet vejo as pessoas fazendo tudo em uma classe só.

esse paradigma é muito complicado de se entender e tem muita gente que ACHA que sabe, eu mesmo tenho minhas dificuldades também.

Desenvolvi um sistema achando ser Orientado a Objeto e quanto mais estudava mais eu via que não tinha nada que tornasse o meu sistema OO.

Olha que eu criava Objetos, Métodos e tudo mais só que no final eu utilizei 1 dos principios e utilizei muito mal.

Não estou expert no assunto eu dou minha contribuição mas sei que jaja vem alguém e vai dar uma explicação mais técnica.

 

o meu ponto é que, nem tudo que você ve na internet esta certo.

Mas na Imasters por existir várias pessoas que entendem da mesma coisa umas corrigem as outras e a chance de erro é menor.

 

sobre o design pattern esta aqui uma boa discussão e com exemplo do que falei de um corrigirem os outros.

http://forum.imasters.com.br/topic/425372-padrao-active-record/

 

de forma geral tem muito chão mas para primeiro contato creio que esta bom.
Vou te passar o que vai resolver sua vida.

 

http://forum.imasters.com.br/forum/159-curso-de-php/

 

Leia desde Objeto x Classe.

 

http://imasters.com.br/linguagens/php/hangout-sobre-php-e-orientacao-a-objetos/

 

e aqui uma discussão na qual eu fui muito corrigido inclusive.

http://forum.imasters.com.br/topic/487582-primeiro-projeto-php-orientado-a-objeto/

Compartilhar este post


Link para o post
Compartilhar em outros sites

Enrico, eu tenho lido bastante sobre o assunto. O livro do Pablo Dall'Oglio aborda alguns patterns. Mas fico perdido sobre qual caminho seguir inicialmente. São muitos patterns e eu gostaria de saber qual adotar no começo, pra pegar o jeito.

 

Sei que essa questão de qual pattern adotar é um tanto relativa, já que cada um tem vantagens e desvantagens e uns podem ser melhores que outros em determinadas situações. Só acho que como o assunto é muito extenso seria interessante que existisse um "caminho inicial" e é isso que não estou achando. Dessa forma fico com o pé atrás de avançar e pegar vícios errados.

 

Por isso criei o tópico, para que outras pessoas mais experientes no assunto pudessem avaliar e fazer críticas e quem sabe me dizer onde estou errando e o que devo melhorar. A partir disso acho que me sentirei mais seguro sobre como devo seguir, já que minha dificuldade não é com conceitos de OO, e sim sobre como aplicá-los da melhor forma.

Compartilhar este post


Link para o post
Compartilhar em outros sites
  Em 25/03/2013 at 17:13, Enrico Pereira disse:

Outra coisa importante para resolução de problemas em OO é conhecer design patterns, eles são uma mão na roda na hora de planejar o design do código.

Na verdade, não é necessário conhecer design pattern. O que é necessário são os design principles, principlamente o S.O.L.I.D, você pode desenvolver um sistema todo sem utilizar designer patterns e possuir uma excelente modelagem de classes.

 

S.O.L.I.D. é o acrônimo dos cinco primeiros princípios identificados por Robert "UncleBob" Martin. Ele definiu onze no total, os cinco primeiros para o design de classes e os seis restantes para o design de packages.

 

Design patterns são soluções reutilizáveis para problemas conhecidos. Design e modelagem de dados não são um problema, logo, não é da área dos design patterns. Um design ruim, isso sim é um problema, mas também não é resolvido com design patterns. É resolvido através de uma refatoração de código.

 

Depois de entender bem os conceitos básicos de orientação à objetos, você deve conhecer os princípios. Só para então, se tiver um problema, buscar a solução nos patterns.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Sim, S.O.L.I.D. é algo fundamental em OO, mas patterns são extremamente úteis e ajudam sim na modelagem.

 

Sobre os patterns, eu aprenderia todos os patterns G.O.F., aqui no fórum, tem muitos deles neste tópico: http://forum.imasters.com.br/topic/402329-padroes-gof/ e existe um vasto material por toda a internet. A "grande figura" é que você precisa eliminar hábitos antigos, de programação procedural, evite IF's, Switch's, e busque sempre um código legível e extensível.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Ao pessoal que quer estudar, com dedicação, eu havia, um tempo atrás, separado um material para um usuário do fórum, claro que possuem "partes" específicas para o que ele desejava, mas mesmo assim, abrange todo o assunto que você gostaria. Fica a seu critério a leitura, entretanto, muito recomendada.

http://forum.imasters.com.br/topic/479646-boas-praticas-php/?p=1907012

Compartilhar este post


Link para o post
Compartilhar em outros sites
  Em 25/03/2013 at 10:02, felipe_zmm disse:

Programo em PHP já há algum tempo, porém procedural e estou querendo me familiarizar com o paradigma OO. Para começar, comprei o livro "PHP - Programando com Orientação a Objetos", do Pablo Dall'Oglio.

Quanto ao livro, nunca li, mas é bem falado.
  Em 25/03/2013 at 10:02, felipe_zmm disse:

Bom, primeiro de tudo para começar eu resolvi que faria uma classe de Usuários. Comecei colocando as propriedades e métodos getters e setters, além de métodos para login e logout. Mas então achei que deveria separar as duas coisas [...]

Granularidade VS Responsabilidade.

 

Se você tiver uma classe que apenas persiste estados mas não tem responsabilidade, você está aumentando a granularidade, aumentando complexidade sem ganhar nada em troca. Padrões como DataMapper e ValueObject agregam valor a uma classe sem Interface pelo contexto. De modo geral, sem um excelente motivo, uma classe que apenas armazena estados é incorreta.

  Em 25/03/2013 at 10:02, felipe_zmm disse:

 

 




class ControleLogin
    {
        public function validarUsuario($login, $senha)
        {
            $this->_bd = new BD();

 

 

 

Sério mesmo? Cada validação é "Um novo banco"??
  Em 25/03/2013 at 10:02, felipe_zmm disse:

 

 




class ControleLogin
    {
        public function validarUsuario($login, $senha)
        {
            // [...]
            $qry = "SELECT COUNT(*) FROM {$this->_tabela} "
                 . "WHERE usuario = :login AND senha = :senha";

 

 

 

[inline]count(id)[/inline] é bem melhor que [inline]count(*)[/inline]. Prefira evitar o coringa [inline]*[/inline]. Se precisar de outros campos, especifique. Outra coisa: É sempre a mesma consulta para todas as validações. Armazene numa propriedade privada ao invés de gerá-la a cada chamada do método.
  Em 25/03/2013 at 10:02, felipe_zmm disse:

 

 




class ControleLogin
    {
        public function logout()
        {
            session_start();
            unset($_SESSION);
            session_destroy();
        }

 

 

 

Iniciar a sessão para destruí-la????? Apenas verifique se existe uma sessão ativa e, quando necessário, destrua.
  Em 25/03/2013 at 10:02, felipe_zmm disse:

 

 




class ControleLogin
{
        public function usuarioLogado()
        {
            session_start();
            
            if ((!isset($_SESSION['login'])) || (!isset($_SESSION['validado'])))
            {
                return false;
            }
            
            return true;
        }

 

 

 

Retorne direto o teste


    session_start();
    return isset($_SESSION['login']) and isset($_SESSION['validado']);
  Em 25/03/2013 at 10:02, felipe_zmm disse:

 

 




class Usuario
    {
        private $_id;
        private $_nome;
        private $_sobrenome;
        private $_email;
        private $_login;
        private $_senha;
        private $_status;
        
        public function getId()
        {
            return $this->_id;
        }
        public function setId($id)
        {
            if ($id > 0)
            {
                $this->_id = abs($id);
            }
        }
        
        public function getNome()
        {
            return $this->_nome;
        }
        public function setNome($nome)
        {
            if (is_string($nome))
            {
                $this->_nome = $nome;
            }
        }

A classe Usuario contém apenas getters e setters. A minha primeira dúvida surge aí: As classes ControleLogin e Usuario deveriam ser uma só ? Qual seria a forma mais correta de fazer isso ?

 

 

 

 

Um porteiro é um funcionário de um prédio. Mas nem todo funcionário do prédio é porteiro ;)

  Em 25/03/2013 at 10:02, felipe_zmm disse:

Bom, a dúvida que me surgiu neste ponto foi quanto à simplicidade de uso dessas classes.

http://en.wikipedia.org/wiki/KISS_principle

  Em 25/03/2013 at 10:02, felipe_zmm disse:

No caso de fazer um Insert, a minha aplicação teria que instanciar a classe Usuario, alterar sua propriedades, depois instanciar a classe UsuarioMapper e persistir os dados. Por algum motivo me parece pouco prático e portanto incorreto, não sei se é apenas impressão pela falta de costume. Eu deveria fazer um class Usuario extends UsuarioMapper para facilitar ? Isso é correto ?

Seu mapper mapeia para um banco de dados relacional, com algumas configurações de conexão.

 

Eu posso vir e implementar um mapper que mapeia para a memória RAM do sistema. Outro Dev pode implementar um mapper que mapeia para um banco NoSQL, outro que mapeia para arquivos XML armazenados no disco, etc, etc, etc.

 

Nenhum de nós precisou tocar na classe Usuario. Isso parece bom ou ruim para você?? Essa é a mágica!

Compartilhar este post


Link para o post
Compartilhar em outros sites

Só um adendo: em se tratando de mapeamento relacional, eu não gosto nem do Active Record, por violar praticamente TODOS os princípios OO e nem do Data Mapper, por ter uma visão extremamente oposta, aumentando a granulidade do sistema, como o colega Evandro citou.

 

Para esse propósito específico, sugiro você conhecer os padrões Table Row Gateway e Data Row Gateway, que não co-irmãos.

 

:seta: http://imasters.com.br/linguagens/php/padroes-tabledatagateway-e-tablerowgateway-teoria-e-pratica/

 

Agora sobre a compreensão real da orientação a objetos, o único jeito de aprender é errando. Faça, refaça, refatore sem medo de ser feliz. Um dia as coisas passarão a fazer sentido.

 

A Orientação a Objetos surgiu com o intuito de aproximar a programação do mundo real. Jamais se esqueça disso. Uma vez que isso estiver claro para você, não terão mais segredos.

Compartilhar este post


Link para o post
Compartilhar em outros sites
  Em 25/03/2013 at 21:17, Enrico Pereira disse:

Só uma coisa, meio que irrelevante, mas: não use o _, polui o código, é uma prática de linguagem sem visibilidade, o que não é o caso do PHP.

 

A utilização do _ em propriedades protected e private estão no standards da Zend e Pear, por isso adotei. Li também em algum livro que não me recordo qual que era uma boa prática.

 

 

  Em 25/03/2013 at 20:50, Evandro Oliveira disse:

 

Granularidade VS Responsabilidade.

 

Se você tiver uma classe que apenas persiste estados mas não tem responsabilidade, você está aumentando a granularidade, aumentando complexidade sem ganhar nada em troca. Padrões como DataMapper e ValueObject agregam valor a uma classe sem Interface pelo contexto. De modo geral, sem um excelente motivo, uma classe que apenas armazena estados é incorreta.

Eu posso vir e implementar um mapper que mapeia para a memória RAM do sistema. Outro Dev pode implementar um mapper que mapeia para um banco NoSQL, outro que mapeia para arquivos XML armazenados no disco, etc, etc, etc.

 

Nenhum de nós precisou tocar na classe Usuario. Isso parece bom ou ruim para você?? Essa é a mágica!

 

 

E granularidade é algo ruim ? Eu imaginava que seria melhor separar as camadas o máximo possível.

 

Quanto a implementar diferentes mappers sem mexer na classe Usuario acho que é algo bom. Mas isso não vai contra o argumento de que seria um aumento de complexidade sem ganhar nada em troca ?

 

  Em 25/03/2013 at 21:26, Henrique Barcelos disse:

Só um adendo: em se tratando de mapeamento relacional, eu não gosto nem do Active Record, por violar praticamente TODOS os princípios OO e nem do Data Mapper, por ter uma visão extremamente oposta, aumentando a granulidade do sistema, como o colega Evandro citou.

 

Para esse propósito específico, sugiro você conhecer os padrões Table Row Gateway e Data Row Gateway, que não co-irmãos.

 

Henrique,

 

O livro do Pablo Dall'Oglio aborda os patterns que você mencionou.

 

Quanto ao Table Data Gateway realmente não fui muito com a cara dele por ser stateless. Como estou aprendendo, não acho que seja legal criar classes que não utilizam alguns conceitos de OO, já que este pattern não tem propriedades.

 

Já o Row Data Gateway me agradou mais, porém é muito parecido com o ActiveRecord, não ? Segundo o livro a única diferença é que o ActiveRecord também descreve o comportamento do objeto, enquanto o RDG não.

Compartilhar este post


Link para o post
Compartilhar em outros sites
  Em 25/03/2013 at 21:54, felipe_zmm disse:

A utilização do _ em propriedades protected e private estão no standards da Zend e Pear, por isso adotei. Li também em algum livro que não me recordo qual que era uma boa prática.

 

Esses standarts são defasados. O próprio Zend Framework não usa mais.

 

 

 

  Em 25/03/2013 at 21:54, felipe_zmm disse:

E granularidade é algo ruim ? Eu imaginava que seria melhor separar as camadas o máximo possível.

 

Quanto a implementar diferentes mappers sem mexer na classe Usuario acho que é algo bom. Mas isso não vai contra o argumento de que seria um aumento de complexidade sem ganhar nada em troca ?

 

Não. Separar o estado em outra(s) classe(s) é uma boa prática.

 

 

 

  Em 25/03/2013 at 21:54, felipe_zmm disse:

Quanto ao Table Data Gateway realmente não fui muito com a cara dele por ser stateless. Como estou aprendendo, não acho que seja legal criar classes que não utilizam alguns conceitos de OO, já que este pattern não tem propriedades.

 

Já o Row Data Gateway me agradou mais, porém é muito parecido com o ActiveRecord, não ? Segundo o livro a única diferença é que o ActiveRecord também descreve o comportamento do objeto, enquanto o RDG não.

 

Eles andam juntos, stateless não é um problema, o único estado problemático é o global o estado vazio não é problema.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Eu tenho lido bastante que o problema do ActiveRecord é quebrar o SRP. Então apesar de parecidos o Row Data Gateway não o quebra, já que não descreve comportamento ?

 

Outra coisa, alguém poderia me explicar a diferença de DAO e DataMapper ? Acho os dois muito parecidos.

Compartilhar este post


Link para o post
Compartilhar em outros sites
  Em 25/03/2013 at 23:00, felipe_zmm disse:

Eu tenho lido bastante que o problema do ActiveRecord é quebrar o SRP. Então apesar de parecidos o Row Data Gateway não o quebra, já que não descreve comportamento ?

 

Outra coisa, alguém poderia me explicar a diferença de DAO e DataMapper ? Acho os dois muito parecidos.

Database Access Object é apenas uma API que abstrai as diferenças entre os bancos de dados.

 

DataMapper faz a relação entre a entidade persistida no DB e o Objeto da aplicação. Podem se complementar, mas uma coisa é independente da outra.

 

ActiveRecord viola o SRP quando passa a pregar coisas como

$user = new User();
$user->save();

A menos que seu usuário seja um super-heroi, User não salva nada nem ninguém. Não é sua responsabilidade. Um usuário cria posts, adiciona imagem, altera configurações, cria novos usuários, altera permissões, mas tudo isso através da interface provida a ele. Um usuário Usa um sistema

$system->setUser($user);
$system->createNewUser('name', 'sex', 'age', array('permission', 'permission', 'permission'));

Exception::PermissionDenied => User {$user->name} has no permission to create new users.

 

  Em 25/03/2013 at 21:54, felipe_zmm disse:

A utilização do _ em propriedades protected e private estão no standards da Zend e Pear, por isso adotei. Li também em algum livro que não me recordo qual que era uma boa prática.

https://github.com/php-fig/fig-standards

 

  Em 25/03/2013 at 21:54, felipe_zmm disse:

E granularidade é algo ruim ? Eu imaginava que seria melhor separar as camadas o máximo possível.

Em excesso sim. Não faça um trabalho que você não vai tirar proveito dele. Ter um sistema flexível é diferente de ter um sistema capaz de fazer tudo. Não crie dependências e acoplamento desnecessariamente. Não tente resolver problemas que você ainda não tem. Separe as camadas o máximo possível e o mínimo necessário. Senão, logo logo, vocẽ terá interfaces com um método em cada uma.

 

Suas classes devem conter o equilíbrio entre a quantidade de componentes que elas usam e a quantidade que elas poderão/deverão utilizar futuramente.

  Em 25/03/2013 at 21:54, felipe_zmm disse:

Quanto a implementar diferentes mappers sem mexer na classe Usuario acho que é algo bom. Mas isso não vai contra o argumento de que seria um aumento de complexidade sem ganhar nada em troca ?

Se você acha que não se ganha nada em troca, como poderia ser algo bom?

  Em 25/03/2013 at 21:54, felipe_zmm disse:

 

Quanto ao Table Data Gateway realmente não fui muito com a cara dele por ser stateless. Como estou aprendendo, não acho que seja legal criar classes que não utilizam alguns conceitos de OO, já que este pattern não tem propriedades.

Pesquise (superficialmente) sobre Proxy, Adapter, Builder e Façade.

Compartilhar este post


Link para o post
Compartilhar em outros sites
  Em 25/03/2013 at 23:25, Evandro Oliveira disse:

 

A menos que seu usuário seja um super-heroi, User não salva nada nem ninguém. Não é sua responsabilidade. Um usuário cria posts, adiciona imagem, altera configurações, cria novos usuários, altera permissões, mas tudo isso através da interface provida a ele. Um usuário Usa um sistema

$system->setUser($user);
$system->createNewUser('name', 'sex', 'age', array('permission', 'permission', 'permission'));

Exception::PermissionDenied => User {$user->name} has no permission to create new users.

 

Mas não é isso que meu UsuarioMapper faz ? Ele recebe uma instância da classe Usuario e persiste as informações no banco de dados.

 

Vou pesquisar sobre os assuntos que você propôs.

Compartilhar este post


Link para o post
Compartilhar em outros sites
  Em 25/03/2013 at 23:25, Evandro Oliveira disse:

Em excesso sim. Não faça um trabalho que você não vai tirar proveito dele. Ter um sistema flexível é diferente de ter um sistema capaz de fazer tudo. Não crie dependências e acoplamento desnecessariamente. Não tente resolver problemas que você ainda não tem. Separe as camadas o máximo possível e o mínimo necessário. Senão, logo logo, vocẽ terá interfaces com um método em cada uma.

 

Sim! Eu pensava o contrário 2 meses atrás, mas fui percebendo, que estava virando maluco, criando interfaces para tudo, e sem razão, sem necessidade alguma, perdendo a racionalidade, muitas vezes a flexibilidade e o desacoplamento são falácias. Você pode sim, seguir patterns e os princípios S.O.L.I.D. sem virar um "louco".

Compartilhar este post


Link para o post
Compartilhar em outros sites

Evandro,

 

No seu primeiro post neste tópico você ficou "assustado" com o fato de eu ter dado um session_start para depois dar um session_destroy. Mas pelo que eu sempre soube para qualquer manipulação de sessão que eu fizer preciso iniciá-la, não ? Mesmo assim fui tentar remover o session_start do método logout e o mesmo parou de funcionar como deveria, não limpando a sessão.

Compartilhar este post


Link para o post
Compartilhar em outros sites

×

Informação importante

Ao usar o fórum, você concorda com nossos Termos e condições.