Hoje vou abordar um dos temas que mais me interessa dentro do mundo do desenvolvimento de 소프트웨어: escrever códigos melhores.

Dentro deste tema costuma-se falar de arquitetura de software, padrões de projeto, design de software 등

Nesta série de artigos vou abordar o SOLID que é um princípio de design de software orientado a objeto (OOD). 기본, SOLID é um acrônimo para:

S - Single Responsibility Principle
O - Open-closed Principle
L - Liskov Substitution Principle
I - Interface Segregation Principle
D - Dependency Inversion Principle

Vamos entender como funciona cada um deles e exemplicar usando o PHP. Laravel의 세부 사항은 MVC에서 MVC로 확장할 수 있는 프레임워크이며, 응용 프로그램에서 사용할 수 있고, 구성/작업을 구성할 수 있습니다.

Então, neste primeiro artigo vamos abordar o primeiro dos princípios de forma detalhada.

단일 책임 원칙

(Princípio da Responsabilidade Única)

Uma classe deve ter uma e apenas uma razão para mudança, significando que uma classe deve ter apenas uma responsabilidade.

Este é o primeiro, mais simples, e mais importante princípio, pois parte da premissa que toda classe deve ter apenas 1 objetivo quando se trata do fluxo de uma requisição do 소프트웨어.

Vamos dar uma olhada no exemplo abaixo:

class UserRegistrationController extends Controller
{
    public function register(Request $request)
    {
        $attributes = $request->all();
        if($attributes['type'] === 'employee') {
            $this->saveEmployee($attributes);
        }

        if($attributes['type'] === 'contractor') {
            $this->saveContractor($attributes);
        }

        return view('user.register');
    }

    public function saveEmployee($request)
    {
        DB::table('employees')->insert([
            /* Dados do funcionário aqui... */
        ]);
    }

    public function saveContractor($request)
    {
        DB::table('employees')->insert([
            /* Dados do terceirizado aqui... */
        ]);
    }
}

Esta classe acima viola o princípio da responsabilidade única pelos motivos a seguir:

Mistura가 응답합니다. Um Controller deve ser responsável por apenas gerenciar 요청 e 응답.

예를 들어, 서비스에서 분리된 서비스에서 다시 청구할 수 있습니다. (Qu não tem como padrão no Laravel, mas podemos criá-la manualmente)

Operações com o banco de dados também devem estar em outra camada. No Laravel, por padrão, usamos o Model. 저장소에 대한 정보를 사용할 수 없습니다. (mesmo caso do 서비스)

Vamos는 클래스를 수정합니다.

class UserRegistrationController extends Controller
{
    protected $userService;

    public function __construct(UserService $userService)
    {
        $this->userService = $userService;
    }

    public function register(Request $request)
    {
        $userService->register($request);

        return view('user.register');

    }
}

Aqui deixamos o Controller isolado com a sua única responsabilidade: gerenciar a request e a response.

Laravel, para podermos adicionar uma camada de comunicação com a classe atual, nós usamos a injeção de dependsência nativa do framework. Basta adicionar a classe desejada como paraâmetro no construtor e atribuí-la em uma propriedade da classe. E eu fiz isso adicionando a classe UserService .

Vamos entender 아고라 클래스UserService :

class UserService
{
    protected $employeeRepository;
    protected $contractorRepository;

    public function __construct(
        EmployeeRepository $employeeRepository,
        ContractorRepository $contractorRepository
    )
    {
        $this->userRepository = $userRepository;
        $this->contractorRepository = $contractorRepository;
    }

    public function register(Request $request)
    {
        $attributes = $request->all();
        if($attributes['type'] === 'employee') {
            $this->employeeRepository->save($attributes);
        }

        if($attributes['type'] === 'contractor') {
            $this->contractorRepository->save($attributes);
        }
    }
}

O Service é o local onde colocamos toda a regra de negócio, como é o caso do condicional que usamos para identificar o tipo de usuário.

Aqui também usamos a injeção de dependsência, mas importamos 2 클래스. Exatamente os Repositories dos tipos de usuário. Como o Model é a Representativeação da tabela do banco dentro da aplicação, eo Repository é reponsável pela operação de banco de cada Model, nada mais coerente mantê-los separados.

Vamos entender 아고라 os 리포지토리:

class EmployeeRespository
{
    protected $employee;

    public function __construct(Employee $employee)
    {
        $this->employee = $employee;
    }

    public function save(array $attributes)
    {
        $this->employee->insert($attributes);
    }
}

class ContractorRespository
{
    protected $contractor;

    public function __construct(Employee $contractor)
    {
        $this->contractor = $contractor;
    }

    public function save(array $attributes)
    {
        $this->contractor->insert($attributes);
    }
}

Em ambos os Repositories utilizamos a mesma estrutura: injeção de dependsência com oreceivivos Models, e um método save() .

Dessa maneira, separamos as responsabilidades em camadas, deixando o código mais legível e com uma arquitetura mais correta.

No próximo artigo vou abordar o segundo princípio: 개방 폐쇄 원칙(Princípio Aberto-fechado).

Espero que você tenha gostado. Dúvidas e feedbacksão semper muito bem vindos.

추신: 추가 서비스 e 리포지토리는 Laravel 응용 프로그램으로서 파스타app/Services 및 app/Repositories 추가 클래스 설명서입니다.

PPS: Neste exemplo abordei apenas o essencial para explicá-lo, deixando de fora imports, return, validationators, etc.

PPPS: Eu sei que o ideal seria terum Model User e estender para Employee e Contractor . Mas para o exemplo ficar mais claro, deixei-os separados mesmo.