SOLID Flashcards
Explique o [S] - Single Responsibility Principle do SOLID
Separar coisas que MUDAM POR MOTIVOS DIFERENTES.
Mover responsabilidades para classes específicas garantir que a classe tem a sua própria responsabilidade.
Use case da aula: Lembrar das taxas dos itens que mudam conforme o tipo do item (cerveja, whisky..) tem taxa diferente pra cada tipo de item, o calculo da taxa do item estava na classe Ordem (que representa o pedido) e foi movido pra classe Item
Explique o [O] - Open/Closed Principle do SOLID
Descrição do princípio:
Devemos estar fechados para modificação e abertos para extensão. Uma classe deve poder ser herdada para novos comportamentos sem ter que alterar a super classe.
Use case da aula: Lembrar do caso onde o calculo de um novo item acarretava em um novo if no código testando qual era o item para poder calcular a taxa, ao invés disso criamos uma especialização de Item Whisky.ts, Beer.ts e nela colocamos um método que calcula a taxa, nesse caso a classe Item não foi modifica (fechada para modificação) mas foi especializada em classes de itens (aberta para extensão).
Explique o [L] - Liskov Substitution Principle do SOLID?
Descrição do princípio:
Se S (Beer, Whisky, Water) é subclasse de T (Item), em um programa deve ser possível substituir instâncias de T (Item) por instâncias de S (Beer, Whisky, Water), SEM QUEBRAR O FUNCIONAMENTO DO PROGRAMA
Aqui estamos falando de expectativa da aplicação e não sobre regra de negócio.
Use case da aula: Lançou uma exceção ao chamar a função que calcula a taxa na especialização do Item (na classe Water)
Explique o [I] - ISP (Interface Segregation Principle) do SOLID?
Descrição do princípio:
Cuidado com interfaces muito abrangentes, não obrigue subclasses a implementar métodos que elas não precisam.
Segregar comportamentos, para classes mais específicas. Fazer um fork de uma interface quando necessário.
Use case da aula: Criação de uma nova classe abstrata que extende Item e que contem o método de calculo de taxas (TaxItem), pois nem todo item precisa calcular taxas, logo apenas o Item que precisa calcular taxas deve estender de TaxItem
[D] - DIP (Dependency Inversion Principle)
Descrição do princípio:
Módulos de alto nível não devem depender de módulos de baixo nível. A classe deve depender de uma abstração. Receber as dependências na classe.
Modulos de alto nivel = Mais perto da regra de negócio
Módulos de baixo nivel = Mais perto do hardware
Use case da aula: A classe Order estava lendo um arquivo diretamente (usando fs module) do sistema operacional, foi criado uma classe abstrata e uma classe que implementa essa abstração, a classe que implementa contém o método que le o arquivo do sistema e foi passada como dependência para a classe Order que por sua vez apenas chama o método responsável por retornar a mensagem.
[L] - Liskov Substitution Principle explique o conceito “Pré-condições não podem ser fortalecidas
Deixar de aceitar ENTRADAS que a superclasse considera valida.
Use case da aula: na classe Person não aceita idades abaixo de 0, na sua especialização Employee não aceita idades menores de 18 anos. Se trocar as instâncias poderia haver casos onde a lógica não estaria operando de maneira correta.
[L] - Liskov Substitution Principle explique o conceito “Pós-condições não podem ser enfraquecidas”
Deixando as saídas diferentes da expectativa de quem está chamando o método. Aceitando saídas mais amplas
Use case da aula: a classe Water que é especialização de Item, retorna uma exceção no método de calculo de taxa, mas a super classe esperava o retorno de um número inteiro.
[L] - Liskov Substitution Principle explique o conceito “Invariantes devem se manter constantes”
Se uma subclasse permitir que o estado conceitual da hierarquia de classes fique invalido
Use case da aula: na classe Emloyee aceitar idades negativas, sendo que sua super classe Person não aceita
Segundo Liskov o que são Pré-condições e Pós-condições?
Pré condições são as condições que devem ser verdadeiras antes da execução de um método ou função para que o mesmo gere o resultado esperado.
Ex.: Validação se há saldo na conta antes de executar o saque em uma função da classe ContaBancaria.
Pós condições são as condições que devem ser verdadeiras após a execução de um método ou função. Ex.: Após chamada do método saque da classe ContaBancaria, é feito uma asserção para sabermos se o saque foi efetuado conforme esperado.
