Separar responsabilidades entre as classes

[Eisenheim 67]

Bom dia amigos!

 

Optei em postar o código antes e deixar a dúvida no final. Lembrando que isso é apenas um caso de estudo.

<?php
interface ICrud
{
	public function inserir();	
	public function alterar();	
	public function excluir();	
	//public function listar();	
}
?>

class Cliente
{
		private $id;
		private $nome;
		private $email;
		
		public function __construct()
		{
			
		}
		
		public function setId($id)
		{
			$this->id = $id;
		}
		public function getId()
		{
			return $this->id;
		}

		public function setNome($nome)
		{
			$this->nome = $nome;
		}
		public function getNome()
		{
			return $this->nome;
		}

		public function setEmail($email)
		{
			$this->email = $email;
		}
		public function geEmail()
		{
			return $this->email;
		}
}
?>

<?php

class ClienteDao implements ICrud
{
		private $cliente;	
		
		public function __construct(Cliente $cliente)
		{
			$this->cliente = $cliente;	
		}
		
		public function inserir()
		{
			$this->cliente->setId(1);	
			$this->cliente->setNome("Jeferson");	
			$this->cliente->setEmail("jrs@jrs.com.br");	
		}
		
		public function excluir()
		{
			
		}	

		public function alterar()
		{
			
		}	
			
}

?>

Ao meu ver, minha classe ClienteDao ainda se encontra muito "acoplada" a classe cliente. Nesse ponto é que ainda não saquei como deveria fazer para "retirar" esse acoplamento tornando-a mais abstrata.

 

O problema que eu vejo dessa implementação, é que minha classe cliente pode fazer uso de outras classes, e passar vários objetos para dentro da classe ClienteDao ou diretamente para a classe Cliente ao meu ver não seria a melhor maneira de resolver essa questão.

 

O que os amigos me sugerem?

 

[Leandro Senni 1]

A Classe ClienteDao teria mais a responsabilidade de incluir no banco de dados (montar o SQL), então o Cliente poderia ser alimentado pelo sua aplicação conforme a regra de negocio...

E se for o caso como o Doctrine ter um relacionamento o Cliente usaria de outras classes para mapear esses objetos.

[Gabriel Heming 766]

Ao meu ver, minha classe ClienteDao ainda se encontra muito "acoplada" a classe cliente. Nesse ponto é que ainda não saquei como deveria fazer para "retirar" esse acoplamento tornando-a mais abstrata.

Não pense que sua classe ClienteDAO esta muito acoplada, pois a necessidade de existência dela é ser acesso aos dados do objeto cliente. Por isso você a nomeou DAO (Data Access Object).

 

O problema que eu vejo dessa implementação, é que minha classe cliente pode fazer uso de outras classes, e passar vários objetos para dentro da classe ClienteDao ou diretamente para a classe Cliente ao meu ver não seria a melhor maneira de resolver essa questão.

Sim, ela pode e deve. Como por exemplo, o contato do cliente ser um objeto e sua relação ser de composição.

É de responsabilidade da classe ClienteDAO saber que cliente possui um objeto do tipo Contato, mas as operações CRUD não são de responsabilidade de ClienteDAO e sim, de uma fictícia e futura classe, ContatoDAO.

 

Agora, a forma que você vai criar as responsabilidades entre as classes CRUD, depende da sua modelagem.

 

Exemplo 1 (Deixa a responsabilidade para a Model, ela tem conhecimento das separações)

Exemplo 2 (Deixa a responsabilidade para o DAO, desacoplando a model)

 

O exemplo 2, ao meu ver, é o correto. A ideia dos exemplos foi para mostrar a relação de transactions.

 

Outro detalhe. No momento, para a assinatura da interface ICrud, a implementação da classe ClienteDAO atende suas necessidades, mas no momento em que você for implementar o método listar, descobrirá que a classe ClienteDAO necessita de uma instância de Cliente que não será utilizada para o método listar.

Existem alguns outros padrões que você pode utilizar para separar as responsabilidades entre as camadas de negócio, entidade e crud. Como por exemplo TableDataGateway e TableRowGateway ou DataMapper.

 

Cada padrão possui suas vantagens e desvantagens, mas atendem bem sua necessidade.