Neste artigo, explico como funciona o estágio aqui na Doutbox e, além disso, compartilho a quarta parte do meu projeto como estagiário. Confira!

Se você ainda não leu a Introdução do meu projeto de estágio, clique aqui para ler a parte 1.

3.4.7 SOLID

Tarefa: Estudar as vantagens e desvantagens, exemplificar cada conceito na prática com código (antes e depois).

O SOLID é baseado em 5 conceitos básicos: Single Responsibility (Princípio da responsabilidade única), Open-Closed Principle (Princípio Aberto-Fechado), Liskov Substitution Principle (Princípio da substituição de Liskov), Interface Segregation Principle (Princípio da Segregação da Interface) e Dependency Inversion Principle (Princípio da inversão da dependência).

1. O Single Repository (Princípio da responsabilidade única), é o princípio de que todos os módulos, classes e funções devem atender a apenas uma parte da funcionalidade de um programa, como já foi explicado no tópico anterior.

Figura 14: classe antes de ser aplicado srp

Figura 15: divisão das funções em classes apropriadas com srp

2. O Open-Closed Principle (Princípio Aberto-Fechado), diz que um objeto ou entidade deve estar aberto para extensão, mas fechado para modificações, quando queremos adicionar um novo recurso ou funcionalidade, devemos estender a base e não modificá-la.

Exemplo: deve se definir um tabuleiro ou quadro com uma área, mas inicialmente se foi criado com base em um retângulo, se quiser que seja usado um círculo, será necessário que seja criado um método novo apenas para o círculo:

Figura 16: classe board funciona apenas com retângulo

Definindo um "shape", como classe pai e estendendo dele os formatos fica muito mais fácil adicionar qualquer formato ao "board" desde que seja usado o método area();

Figura 17: classe board funciona de acordo com os formatos que forem implementados

3. O Liskov Substitution Principle (Princípio da substituição de Liskov), diz que uma classe derivada deve ser substituível por sua classe base, ou seja, em um código, se for passado como parâmetro uma classe pai ou sua derivada, o código vai continuar funcionando da forma esperada, sem erros.

Figura 18: mudando de retângulo para quadrado sem LSP (adaptando)

Figura 19: mudando de retângulo para quadrado com LSP

4. No Interface Segregation Principle (Princípio da Segregação da Interface), a baseia-se no ideal de que uma classe não deveria implementar uma interface ou um método que não será usado, essa ideia diz que é melhor criar interfaces mais específicas, do que termos uma interface única mais genérica.

Figura 20: classe sem aplicação do ISP

Figura 21: classe depois da aplicação do ISP

5. Dependency Inversion Principle (Princípio da inversão da dependência), dependa de abstração e não implementação, nós devemos usar mais interfaces invés de implementações, segundo Uncle Bob esse princípio pode ser definido em dois tópicos.

Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender da abstração.

As abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.

Figura 22: código antes da aplicação do DIP

Figura 23: código depois da aplicação do DIP

3.4.8 Boas Práticas com Laravel

Tarefa: com base nos artigos anteriores esse link traz uma visão geral sobre boas práticas, utilizando o conhecimento adquirido nos futuros projetos.

3.4.9 Interface e Usabilidade

Tarefa: Pesquisar e escrever sobre interface e usabilidade

A interface do usuário é onde ele vai interagir com o projeto desenvolvido, então é uma boa prática usar o UI (user interface) design que é o método para criação de interfaces mais amigáveis e fáceis de usar para melhorar a experiência do usuário ao utilizar a aplicação.

Outra boa prática é a utilização de UX (user experience) design, que é um método para melhorar a interação do usuário com a aplicação, não adianta ter todas as telas as telas bem feitas se o projeto não é responsivo, organizado e intuitivo, porque "organizado", bem muitas vezes se tem alguma utilidade do projeto escondida depois de várias camadas, o cliente tem que entrar em várias telas para chegar no ponto final, no meio desse caminho ele pode se perder, etc. fora que deixa a reutilização mais difícil.

Quando o usuário for utilizar o projeto, tudo deve ser apresentado de forma intuitiva para ele, ou seja, quando for dado um retorno de erro usar cores vermelhas, mensagens de sucesso na cor verde, alertas em amarelo, etc. Mas as cores não devem ser o único requisito, apresentar também mensagens simples e diretas para o usuário quanto ao direcionamento.

Ao mostrar textos é importante pensar no tamanho e nas cores de fundo e texto, para seguir o padrão do projeto, mas também para que haja um bom contraste de cores entre eles. Ao criar formulários também deve-se evitar algumas coisas placeholders

Por exemplo, talvez seja melhor adicionar um texto acima ou abaixo, ou quanto a autenticação, se algo estiver errado é interessante apresentar uma mensagem dizendo o que o usuário está errando. É importante disponibilizar botões em padrões como:Botões de confirmação sempre à direita, botões de cancelar algo à esquerda, diferenciados por cores e bem visíveis.

Fontes: www.medium.com / www.hashbangcode.com / www.digitalocean.com / www.thinktocode.com / www.github.com