From fd6645be0fbf16eda784aae164f80598b54e9719 Mon Sep 17 00:00:00 2001 From: Diogo <83793521+DiogoJorge1401@users.noreply.github.com> Date: Wed, 12 Jan 2022 18:31:02 -0300 Subject: [PATCH 1/2] =?UTF-8?q?doc:=20Corre=C3=A7=C3=A3o=20ortogr=C3=A1fic?= =?UTF-8?q?a?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 1e4ed15..31d2fbb 100644 --- a/README.md +++ b/README.md @@ -1691,7 +1691,7 @@ class HttpRequester { Este é um termo muito assustador para um conceito bem simples. É formalmente definido como "Se S é um subtipo de T, então os objetos do tipo T podem ser substituidos com objetos do tipo S(ou seja, objetos do tipo S podem substituir objetos do tipo T) sem alterar nenhuma propriedade desejáveis daquele programa (correção, tarefa executada, etc.)." E essa é uma definição ainda mais assustadora. -A melhor explicação para isso é se você tem uma classe pi e uma classe filho, então a classe pai e a classe filho podem ser usada sem ocorrer resultados incorretos. Isso pode ainda estar sendo confuso, então vamos dar uma olhada no exemplo clássico Quadrado-Retângulo. Matemáticamente, o quadrado é um retângulo, mas se você modelar o quadrado usando o relacionamento "é-um" via herança, você terá problemas. +A melhor explicação para isso é se você tem uma classe pai e uma classe filho, então a classe pai e a classe filho podem ser usada sem ocorrer resultados incorretos. Isso pode ainda estar sendo confuso, então vamos dar uma olhada no exemplo clássico Quadrado-Retângulo. Matemáticamente, o quadrado é um retângulo, mas se você modelar o quadrado usando o relacionamento "é-um" via herança, você terá problemas. **Ruim:** From efa1dfefeb89e06aafec84ac6c11ed584aaee510 Mon Sep 17 00:00:00 2001 From: Diogo <83793521+DiogoJorge1401@users.noreply.github.com> Date: Wed, 12 Jan 2022 19:15:21 -0300 Subject: [PATCH 2/2] =?UTF-8?q?Corre=C3=A7=C3=A3o=20ortogr=C3=A1fica=20de?= =?UTF-8?q?=20palavras=20no=20t=C3=B3pico=20SOLID?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 31d2fbb..1b0db33 100644 --- a/README.md +++ b/README.md @@ -1548,7 +1548,7 @@ const query = new QueryBuilder() ## SOLID -### Principio da única responsabilidade (Single Responsabiliy Principle) +### Princípio da responsabilidade única (Single Responsabiliy Principle) Como dito em Código Limpo, "Não deve haver mais de um motivo para alterar uma classe". É tentador lotar uma classe com várias funcionalidades, como se você só pudesse carregar uma mala em uma viagem. O problema disso é que sua classe não será conceitualmente coesiva e posteriormente te trará vários motivos para mudar. Reduzir a quantidade de vezes que você precisa mudar uma classe é importante. É importante pois se muitas funcionalidades estão contidas em uma classe e você altera um pedaço disso, pode ser difícil entender como isso irá afetar os módulos dependentes da sua classe/do seu código. @@ -1598,7 +1598,7 @@ class UserSettings { **[⬆ ir para o topo](#table-of-contents)** -### Prinpio do Aberto/Fechado (Open/Closed Principle) +### Princípio do Aberto/Fechado (Open/Closed Principle) Como dito por Bertrand Meyer, "entidades em software (classes, módulos, funções, etc.) devem ser abertas para extenções, mas fechadas para modificações." Mas o que isso significa? Este princípio diz, basicamente, que você deve permitir que seus usuários adicionem novas funcionalidades sem alterar código já existente. @@ -1687,7 +1687,7 @@ class HttpRequester { **[⬆ ir para o topo](#table-of-contents)** -### Principios da Substituição de Liskov (Liskov Substitution Principle) +### Principio da Substituição de Liskov (Liskov Substitution Principle) Este é um termo muito assustador para um conceito bem simples. É formalmente definido como "Se S é um subtipo de T, então os objetos do tipo T podem ser substituidos com objetos do tipo S(ou seja, objetos do tipo S podem substituir objetos do tipo T) sem alterar nenhuma propriedade desejáveis daquele programa (correção, tarefa executada, etc.)." E essa é uma definição ainda mais assustadora. @@ -1793,7 +1793,7 @@ renderLargeShapes(shapes); **[⬆ ir para o topo](#table-of-contents)** -### Principio da Segragação de Interface (PSI) +### Princípio da Segregação de Interface (PSI) PSI afima que "Clientes não deveriam ser forçados a serem dependentes de interfaces que eles não usam". Esse princípio é muito relacionado ao Princípio da única responsabilidade. O que isso realmente significa é que você deve sempre projetar suas abstrações de uma maneira que os clientes que estão usando os métodos expostos não obtenham a "a torta inteira". Isto também inclui aos clientes o dever implementar metódos que eles, na realidade, não precisam.