[MÚSICA] [MÚSICA] Olá, bem vindo ao curso sobre TDD. Eu sou Clovis Fernandes e hoje iremos falar sobre os Princípios SOLID, que são usados para os projetos de classes. Os princípios SOLID ajudam a [INCOMPREENSÍVEL] dependências entre as classes. o nível que a gente vai trabalhar com esses princípios é no nível das classes. Embora envolva a refatoração de alguns métodos também, mover método para lá ou para cá e assim por diante. Olha o que vocês estão vendo aqui, isto é os princípios SOLID. Quer dizer, português, SOLID é uma [INCOMPREENSÍVEL] correspondem a uma coisa [INCOMPREENSÍVEL] desenvolver e dar mais solidez ao seu processo de desenvolver, está certo? Na verdade, o que a gente obtém no [INCOMPREENSÍVEL] é o contrário do SOLID, nós vamos encontrar software mais flexível, mais fácil de gerenciar. Essa é a ideia na verdade. Os princípios SOLID são 5, são 5 princípios que foram proposto pelo Uncle Bob. O objetivo é trabalhar no nível do projeto de classes, eu vou examinar se as classes estão adequadas a esses princípios, está certo? Essa é a ideia. Nós já vimos que existem 3 grandes problemas, no desenvolvimento de software orientado a objetos. Expressar a intenção, que você tem que dar nomes apropriados a métodos, variáveis de instância, classes, interfaces, variáveis temporárias também, está certo? A parte de duplicação de código, você ter código redundante, e obviamente que ter código redundante significa que você vai ter muitas dependências quando alguma mudança nesses códigos ocorreu, você tem que mudar cada desses lugares, está certo? Mas a existem outras dependências que não são decorrentes apenas de código duplicado, está certo? Então, o SOLID vai ajudar a trabalhar com isso, está certo? Dos pontos principais que a gente usa, é o conceito de abstração, acoplamento abstrato. O uso de classes abstratas, o uso de interfaces de JAVA, está certo? É que isso é que vai ajudar a reduzir as dependências entre as classes. Outro ponto importante, é balancear a coesão da classe com as suas dependências. A coesão da classe significa que você, para uma dada tarefa que você, vocês lembram lá do CRC, não é? Eu descrevia o que uma classe, ou cartão CRC [INCOMPREENSÍVEL] está certo? E essa descrição, a gente pode chamar de tarefa, está certo? A coesão significa que para atingir essas tarefas, desfazer [INCOMPREENSÍVEL] para que uma classe era responsável, nós definimos conjunto de responsabilidades que estavam de acordo com essa tarefa, está certo? Então, a coesão que nós queremos, é uma coesão alta, ou seja, grau maior de fazer com que o grupo de responsabilidades da classe correspondam à finalidade da classe, à tarefa da classe, está certo? Isso é a coesão, então a gente quer uma coesão alta. Por outro lado, ao desenvolver software, nós distribuímos a inteligência desse software entre várias classes. Então, vai existir dependências entre as classes. O grande desejo nosso é que as dependências sejam baixas, o que se chama de baixo acoplamento. Que ter dependências é o acoplamento, num baixo acoplamento. E ao longo que vamos desenvolvendo isso no TDD, nós vamos estar balanceado, alguns momentos a gente não é tão coeso, está certo? Talvez menos acoplamento, mais acoplamento e assim por diante, mas a ideia é que você tenha mais coesão e menos acoplamento. Os princípios SOLID ajudam a trabalhar isso. Como consequência, dado que eu já tenho usado, continuo usando aquela expressão da intenção dos nomes que aparecem no meu programa, variáveis de instância, variáveis temporárias, nomes dos métodos, nomes das classes, nomes das interfaces, e seguindo os princípios, vocês vão ver através de outros materiais do nosso curso, e o programa fica mais legível, está certo? Quer dizer, ele vai ajudar ao programa a ficar mais legível, mais extensível, não é, está certo? O que significa ser mais extensível? Significa que vai ser mais fácil de manter, ou seja, quando eu adicionar novo requisito, uma nova responsabilidade, ou mudar requisito ou responsabilidade antiga, está certo, o sistema vai estar muito mais pronto para permitir que você tenha uma facilidade maior fazer essas mudanças e nós sabemos que no desenvolvimento de software, a mudança é inerente, aparece a cada instante. Bom, quais são esses 5 princípios, está certo? SOLID é acrônimo, cada letra dele corresponde a nome do princípio, está certo? Então, o S é para Single, Responsability Principle, também se vocês estão vendo na tabela, se faz uso também muitas vezes da sigla da responsabilidade. A gente fala o conjunto do SOLID como o conjunto dos 5 princípios, e cada uma delas tem a sua sigla que ás vezes vai ser usada e nós iremos usar. O O do SOLID é o Open Closed Principle. Na sigla fica OCP. O L é o Liskov Substitution Principle. Liskov é uma grande cientista de computação, que 1988 propôs esse princípio, que depois acabou ficando com o nome dela. Então, ele é o LSP. O I do SOLID, é o Interface Segregation Principle, está certo? Ele é o ISP. E o D é o Dependency Inversion Principle, ou DIP. Bom, eu vou estar fazendo uma descrição aqui, bastante sumária do que nós depois iremos apresentar outros materiais, vídeo e [INCOMPREENSÍVEL] detalhando cada desses princípios e como eles podem ser usados para você descobrir esses maus cheiros relacionados com a classe, e aplicar técnicas para cada dos princípios, que vão tirar esses maus cheiros, está certo? Então, no SRP, no Single Responsability Principle, a gente tem que lembrar e a responsabilidade que o Uncle Bob usa aí, neste caso deste princípio, não é a responsabilidade que a gente falava anteriormente. Quer dizer, quando eu falava responsabilidade, eu estava falando de o que uma classe faz ou sabe. A responsabilidade do Uncle Bob aqui neste caso, corresponde aquela finalidade da classe, à descrição da classe, está certo? Ou seja, a tarefa que a classe deve fazer, é a isso que ele deve corresponder. Então, nesse sentido, uma classe ela deve ter, segundo esse princípio, uma e apenas uma razão para haver alguma mudança. Ou seja, o que significa isso? Se eu tiver, duas tarefas que estão incorporadas numa classe e isso fica bem claro quando eu estou descrevendo uma classe e eu vou dizer: essa classe faz isso e aquilo e aquilo outro, se tiver mais do que duas, está certo? Então, quando eu estiver falando, eu descubro isso. E significa que, quanto mais finalidades es estiver incorporando na mesma classe, eu tenho acoplamento desnecessários, porque eu posso estar mudando alguma coisa por causa de uma razão, por causa de uma finalidade e aí eu tenho que, isso afeta todo o mundo que depende da minha classe. Está certo? Já o OCP, ele expressa, isso aí foi o Meyer, disse que deve ser possível estender o comportamento de uma classe sem alterar o comportamento existente, está certo? Quer dizer se eu estendo e mudo o comportamento existente anterior, os comportamentos anteriores, comportamentos vão corresponder a responsabilidades, não é? Eu estou violando esse princípio do OCP. Já a LSP, ela garante que o polimorfismo esteja ocorrendo de uma maneira mais adequada. O que é que significa isso? Significa que objetos de uma classe, que você declarou uma variável como sendo de uma classe, eles podem ser substituíveis, está certo por objetos de subclasses [INCOMPREENSÍVEL] mas garantindo que não vai haver nenhuma alteração algum resultado, está certo? Então isso é importante a gente ver. Já o ISP isso tem a ver com interfaces que são muito gordas, ou seja, você tem uma interface que faz muita coisa distinta isso pode ser problema, a ideia é ter interfaces mais magras. O que é que isso significa? Vamos fazer uma analogia com o facto de você usar casaco. Você pode usar casaco que aguenta mais frio está certo? Então, eu posso usar esse casaco quando eu estiver o tempo estiver com menos frio, está certo? Mas eu posso sentir calor se estiver com menos frio, então ele não está me atendendo totalmente, porque ele foi feito para atender com pouco frio e muito frio também, ele atende, mas tem efeito colateral que não é muito bom. Está certo? Então a ideia era que eu tivesse por exemplo, casaco para pouco frio e casaco para muito frio. É isso que a gente faria com essa interface gorda, partiarimos de tal forma, que você possa usar a interface, o casaco, para o frio que esteja fazendo, está certo? Se eu usar casaco para pouco frio com muito frio, eu vou sentir frio, está certo? Então eu tenho que usar no momento adequado. E o DIP, ele tem que ver muito com a abstração, ou seja, você tem uma classe que depende da outra classe, da dependência, porquê? Eu vou acabar colocando uma interface que eu vou fazer que a minha classe dependa dessa interface e agora a classe da qual eu dependia, ela agora depende dessa interface. O que se chama de inversão, está certo? A gente vai mostrar isso com mais detalhes, está certo? Espero que você tenha gostado dos princípios SOLID, nós iremos descrever e detalhar nos materiais educacionais, ou vídeo ou material de leitura no nosso curso. Obrigado. [MÚSICA]
