Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Oi, galera!
Bem, acredito estar postando na área certa, apesar de isso também estar relacionado com a estrutura da aplicação e não necessariamente PHP.
É o seguinte, estou criando uma aplicação orientada a objetos; nela preciso de algumas funções comuns como cadastro de clientes, cadastro de funcionários, alguns produtos cadastrados, é básico, nada difícil de fazer do ponto de vista de um programador: conheço a sintaxe e sei trabalhar legal com a linguagem, mas minha dúvida é sobre a divisão das responsabilidades entre os tipos de objetos.
Por exemplo, no cadastro de um novo cliente, quem está executando esta ação é um funcionário no sistema, mas quem deve ser o responsável pelo método? Ele deve ser parte da classe do funcionário, ou do cliente? Se for na classe "funcionário", seria algo como "cadastrarCliente", mas se for na classe do cliente (o que eu jugo mais correto, pelo princípio de responsabilidade única), seria como?
Desde já agradeço qualquer luz que possam me dar sobre o assunto.
Oi, quimera, obrigado pelo seu post!
Bem, então, implementar níveis de permissões eu consigo fazer bem, vou introduzir um conceito de papéis e capacidades parecidas com o do WordPress, é bem flexível para mim.
Minha dúvida é mais sobre a questão organizacional e metódica do desenvolvimento mesmo, tenho lido sobre OOP, UML, padrões de projeto, enfim, quero uma aplicação mais padronizada...
O funcionário é uma entidade/classe, o cliente é outra entidade/classe.
Geralmente é feito outra classe para inserção do banco de dados tipo ClienteDAO para criar um novo usuário, tipo assim talvez:
class ClienteDAO {
public function inserirCliente(Cliente cliente, Funcionario funcionario) {}
}
DAO é um padrão de projeto mais ou menos antigo e que muita gente ainda usa e existe muita coisa na internet sobre ele. Geralmente você quer que as classes Funcionario e Cliente sejam bem simples somente para representar elas mesmas, e não tomar ações.Oi, Kononome, tudo bem?
Rapaz, nesse tempo que estava esperando algumas respostas no tópico acabei me atentando para o DAO, e que ele supria essa minha necessidade, mas estava esperando alguém mais experiente no assunto para me dar um parecer aqui.
Nesse caso, acho que vou separar assim (que é o que me parece o certo à se fazer): ações em tempo de execução sobre uma entidade serão executadas através de suas respectivas classes (Cliente, Funcionario), já a parte de persistência dos dados vou deixar com as classes DAO (ClienteDAO, FuncionarioDAO).
Como eu disse, programo em PHP há um tempo, mas minhas noções de OOP e padrões de projeto de software só começaram a fluir agora, acho que é uma transição natural.
Enfim, se alguém tiver algo a acrescentar à esta discussão, como exemplos ou links, serei grato. Obrigado, Kononome!
Existem muitos patterns a serem seguidos, só recomendei o mais prático para PHP puro. Geralmente adotamos algum framework para evitarmos o trabalho muito pesado de Padrões de Projeto, pois estes frameworks adotam patterns como MVC, Repositories, ORM, Facades, Dependency Injection e por aí vai.
No Laravel, ele já vem com Models incríveis para você criar um Cliente e Funcionário já conectado ao banco. Após você colocar a configuração do banco de dados em um config do Laravel, você simplesmente faz isso para adicionar ao banco:
// App/Model/Cliente.php
class Cliente extends Eloquent {}
// App/Controller/Cliente.php
class ClienteController extends Controller {
public function inserir() {
$c = new Cliente();
$c->nome = 'Fulano';
$c->save();
}
}
E fazer as ligações entre clientes e funcionários também é coisa de uma função com uma linha dentro. Se você já tem toda a prática de desenvolvimento PHP, recomendo você ter certeza disso lendo isso: [http://br.phptherightway.com/](http://br.phptherightway.com/).
Após isso, você deveria aprender utilizar um framework.
Voltando o assunto de OOP, se você já tem um MVC, o padrão Repositories seria o próximo a ser implementado. É um DAO mais inteligente eu diria.Ah, agradeço suas sugestões!
Bem, conheço e já usei alguns destes frameworks em alguns sistemas aos quais prestei manutenção, ou implementei novas funcionalidades, mas como tenho estudado sobre modelagem de dados e tentado sair daquele ciclo de "aprende/executa", entendendo realmente o quê e porquê estou implementando algo de determinada maneira, me surgiu essa dúvida.
Conheço alguns destes padrões de projeto que você citou, outros não, estou estudando sobre eles ainda, checando a melhor abordagem, até porque, divido o tempo entre estudar e aplicar o que estudei, numa empresa em que eu sou o responsável pelo T.I; é difícil.
Agradeço muito pelo link e pelos conselhos, já usei o Zend, o CodeIgniter, o Cake, mas nunca testei o Laravel, acho que é um bom momento para aprender ainda mais.
Novamente, muito obrigado!
O Single of responsiblity, é especificamente para fazer com que cada classe tenha uma única responsabilidade.
Por exemplo:
Eu tenho um algoritmo desenvolvido para uma loja. Eu possuo uma classe cliente e através dessa classe eu consigo fazer:
Cadastro de novos clientes
Editar clientes existentes
Remover clientes
Adicionar dívidas do cliente
Remover dívidas do cliente
Exibir as dívidas do cliente
Editar dívidas do cliente
Enviar e-mail para cliente quanto estiver próximo ao vencimento.
Essa classe está de acordo com este princípio? De fato não.
Poderíamos ter a seguinte estrutura:
MainCliente
Gerenciamento cliente
Comunicar vencimento
Desta forma cada classe teria sua única responsabilidade.
Você poderia usar um middleware, de forma com que você primeiro faz uma verificação em algo relacionado ao funcionário para depois executar à ação do cliente.
Ou simplesmente o padrão facade.
você pode criar em sua tabela uma coluna com o nível desse funcionário/usuário, e antes de cadastrar você coloca a mensagem "você não pode cadastrar usuários".
id | nome | email | senha | nivel | data
1 | Rick | c@c.c | pass | 0 | 2017-07-06
2 | Alli | a@a.a | pass | 1 | 2017-07-05
3 | John | j@j.j | pass | 2 | 2017-07-04