Iniciante em OO

[felipe_zmm 0]

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á.

[Vinicius Rangel 208]

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?

[felipe_zmm 0]

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 ?

[Vinicius Rangel 208]

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.

 

 

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/

[felipe_zmm 0]

Obrigado Vinicius, vou dar uma olhada nos links que me passou. E fico no aguardo também de outras opiniões e críticas do pessoal.

[Enrico Pereira 299]

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.

[felipe_zmm 0]

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.

[Gabriel Heming 766]

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.

[Enrico Pereira 299]

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.

[Gabriel Heming 766]

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

[Evandro Oliveira 331]

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.

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.

 

 

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

 

 

 

Sério mesmo? Cada validação é "Um novo banco"??

 

 

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.

 

 

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.

 

 

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']);

 

 

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 ;)

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

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

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!

[Enrico Pereira 299]

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.

[Henrique Barcelos 290]

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.

[felipe_zmm 0]

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.

 

 

 

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 ?

 

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.

[Enrico Pereira 299]

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.

 

 

 

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.

 

 

 

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.

[felipe_zmm 0]

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.

[Evandro Oliveira 331]

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.

 

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

 

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.

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?

 

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.

[felipe_zmm 0]

 

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.

[Enrico Pereira 299]

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".

[felipe_zmm 0]

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.