[sugestão] Poderíamos separar as regras de validação presentes no métodos do Validator.php em outro projeto?

[thiagogomesverissimo]

Assim seria possível reutilizar as lógicas de validações em validators no symfony (ou outros projetos PHP).

[wallacemaxters]

Boa tarde,

@thiagogomesverissimo você estaria falando de utilizar o Illuminate\Validation do Laravel em outros projetos?

[thiagogomesverissimo]

Não.
Pensei em separar as validações em outra classe e no arquivo Validator.php só usar essa classe.

Exemplo, atualmente:

   protected function validateCelularComDdd($attribute, $value)
    {
        return preg_match('/^\(\d{2}\)\s?\d{4,5}-\d{4}$/', $value) > 0;
    }

Copiaríamos a validação para um projeto composer externo:

namespace LaravelLegends;
class PtBrValidator
{
   public function celularComDdd($value)
    {
        return preg_match('/^\(\d{2}\)\s?\d{4,5}-\d{4}$/', $value) > 0;
    }
}

E em Validator.php ficaria:

    use LaravelLegends\PtBrValidator;
   protected function validateCelularComDdd($attribute, $value)
    {
        $pt_br_validator = new PtBrValidator;
        return $pt_br_validator->celularComDdd($value);
    }

Assim, a lib LaravelLegends\PtBrValidator poderia ser usada em qualquer projeto PHP.

[insign]

Minha sugestão é que sugira o novo código com um PR

[zabaala]

Acho que o @thiagogomesverissimo está se referindo à técnica de refatoração Method Object.

[zabaala]

Assim, a lib LaravelLegends\PtBrValidator poderia ser usada em qualquer projeto PHP.

Além de ser compatível com outros projetos PHP, seria melhor de testar também.

[thiagogomesverissimo]

@insign, sim concordo. Não mandei a PR antes por que queria verificar com os mantenedores desse projeto se haveria interesse nessa ideia de desacoplamento e portanto não queria enviá-la sem uma discussão prévia. PR enviada #19 e testada.

@zabaala, sim, inclusive, seguindo o link que você enviou, deixei as validações com métodos estáticos.

Após essa PR ser aceita, o próximo passo é criar um novo repositório para a classe GenericPtBrValidators.php (neste caso serial ideal quem mantém essa lib criar, para manter o namespace).

[zabaala]

@thiagogomesverissimo me atentei para duas coisas:

1. Essa (nova?) classe fere o princípio da responsabilidade única, não?
2. Métodos estáticos não são bons para injeção de dependência. Você tinha sugerido implementar algo que pudesse ser utilizado em outros projetos.

Não cheguei a testar. Acredito que esteja funcionando. Mas meu questionamento está relacionado ao pattern e à qualidade. Embasado nisso, deixo até uma pergunta: Qual o padrão adotado pelo projeto?

Abraço.

[thiagogomesverissimo]

@zabaala.

1. sim, fere. Eu desacoplaria os métodos em classes diferentes. Mas isso pode ser feito quando as validações estiverem em um projeto separado. Posso separar os métodos aqui também e mandar um novo PR, se todos estiverem de acordo.

2. Sim, pensei nisso também. Mas não sei se iremos utilizar injeção de dependência no contexto de validações. Mas posso mudar para não estático também se preferirem. Curiosidade, parece que https://github.com/Respect/Validation usa métodos estáticos (não olhei a fundo).

[zabaala]

@thiagogomesverissimo não seria melhor desenhar um diagrama dessas classes? Assim ficaria até mais fácil colaborar.

Curiosidade, parece que https://github.com/Respect/Validation usa métodos estáticos (não olhei a fundo)

Vi aqui, pelo menos as classes das regras não possuem métodos estáticos, só a Validator. Mas só olhei por cima também. 😂

[wallacemaxters]

Galera, ao meu ver isso apenas adicionaria uma complexidade desnecessária ao projeto. Não sei como está o projeto do Laravel atualmente, mas o padrão de nome dos método seguem justamente o padrão utilizado nas versões 4.2 e 5.1, 5.2 (até o 5.3 também, se não me engano) do próprio framework.