/SOLID-Principles

SOLID Principles explained with examples

Primary LanguageTypeScript

SOLID Principles Explained - 🇺🇸

In this repository i'll explain what is solid and their principles, with typescript examples you can find in the local folders, all made by myself. So, lets begin!

What is Solid?

Solid is an acronyms for five good practice concepts in object oriented programming:

Below you can find each concept explained with the links to their respectives codes, use the summary above to get in the sections.

Single Responsability Principle

The class must have one unique responsibility, single responsability principle! Wich means all variables, methods or logic in our entitie must belongs to the entity context! We need to segregate responsibilities, that concept will help us in future with maintenance and class extension. We'll see aggregated objects and dependency injection for this to work well!
(Code Example)

Open-Closed Principle

The OCP says that the class must be open for extension and closed for modification! Which means our class shouldn't try to encompass every scenario, but keep it simple! By following this concept, we will avoid many headaches in future maintenance.
(Code Example)

Liskov Substitution Principle

Liskov Substitution Principle says that we could change our child class for their father class, and the context has to be the same after that. It isn't a good practice implement a logic if our entitie couldn't use it, so we need be careful about our abstract and interface implementations.
(Code Example)

Interface Segregation Principle

This says that, one class its not obligated to implement interfaces that it won't be used. It's almost the same idea as the previous concept, but more focused on how we can implement the idea in practice. So our class doesn't need to implement logic that doesn't fit and doesn't need to implement an interface or method that won't be useful.
(Code Example)

Dependency Inversion Principle

The Dependency Inversion Principle says: "You have to depend on abstrations and not on implementations" wich means, everytime that we have a class agregated to another, we need care about link them by their interfaces (abstration) and not the class itself. That way we can desacoplate more our entities from anothers, creating a code flex scenario.
(Code Example)

Princípios do SOLID explicados - 🇧🇷

Neste repositório vou explicar o que é solid e seus princípios, com exemplos em typescript que você pode encontrar nas pastas locais, todos feitos por mim. Então, vamos começar!

O que é solid?

Solid é um acrônimo para cinco conceitos de boas práticas em programação orientada a objetos:

Abaixo você encontra cada conceito explicado com os links para seus respectivos códigos, use o sumário acima para acessar as seções.

Princípio de Responsabilidade Única

A classe deve ter uma responsabilidade única, princípio de responsabilidade única! O que significa que todas as variáveis, métodos ou lógica em nossa entidade devem pertencer ao contexto da entidade! Precisamos segregar responsabilidades, esse conceito nos ajudará no futuro com manutenção e extensão de classes. Veremos objetos agregados e injeção de dependência para que isso funcione bem!
(Exemplo de código)

Princípio Aberto-Fechado

O OCP diz que a classe deve estar aberta para extensão e fechada para modificação! O que significa que nossa classe não deve tentar abranger todos os cenários, mas sim mantê-la simples! Seguindo esse conceito, evitaremos muitas dores de cabeça em manutenções futuras.
(Exemplo de código)

Princípio da Substituição de Liskov

O Princípio de Substituição de Liskov diz que podemos mudar nossa classe filha pela classe pai, e o contexto deve ser o mesmo depois disso. Não é uma boa prática implementar uma lógica se nossa entidade não puder usá-la, portanto, precisamos ter cuidado com nossas implementações de abstrações e de interfaces.
(Exemplo de código)

Princípio de segregação de interface

Diz que uma classe não é obrigada a implementar interfaces que não serão utilizadas. É quase a mesma ideia do conceito anterior, porém mais focado em como podemos implementar a ideia na prática. Portanto, nossa classe não precisa implementar uma lógica que não se encaixe e não precisa implementar uma interface ou método que não será utilizado.
(Exemplo de código)

Princípio de inversão de dependência

O Princípio da Inversão de Dependências diz: "Você tem que depender de abstrações e não de implementações" ou seja, toda vez que tivermos uma classe agregada a outra, precisamos nos preocupar em vinculá-los por suas interfaces (abstração) e não pela classe em si. Dessa forma podemos desacoplar mais nossas entidades de outras, criando um cenário de código flexível.
(Exemplo de código)