Neste curso, assumimos que você já sabe projetar e desenvolver programas mais complexos em Java, com método e organização graças às boas práticas e princípios exercitados no curso anterior; mas você talvez não se sinta ainda confortável em projetar programas usando técnicas ágeis, como o desenvolvimento guiado por testes (TDD). O objetivo deste curso é expor você aos princípios e práticas de desenvolvimento guiado por testes, tanto para modelar quanto para desenvolver aplicações e componentes de software, sem abandonar os conceitos e princípios de orientação a objetos aprendidos no curso anterior. De fato, pregamos que tais conceitos e princípios fortalecem o emprego do TDD no desenvolvimento ágil de software com mais qualidade. Este curso terá um grande foco em atividades hands-on, permitindo a você captar todos os aspectos práticos da técnica e facilitar a sua aplicação quando estiver projetando e desenvolvendo software de maneira ágil nos próximos cursos. Os conceitos de desenvolvimento de software com Java apresentados neste curso incluem o seguinte: revisão de testes de unidade; automação de testes; desenvolvimento guiado por testes; ciclo do TDD; refatoração de código de produção; ciclo de refatoração; uso de objetos stubs e mocks; boas práticas no TDD; modelagem de software por meio do TDD. Ao final deste curso, você terá amadurecido de tal modo suas habilidades de programação que será capaz de implementar, agora usando o TDD, versões modificadas e estendidas do componente de gamificação constante do Trabalho de Conclusão da Especialização, com base nas boas práticas exercitadas neste curso.
SOLID: Princípios para Projeto de Classes
Loading...
Do curso por Instituto Tecnológico de Aeronáutica
TDD – Desenvolvimento de Software Guiado por Testes
333 classificações
Instituto Tecnológico de Aeronáutica
333 classificações
Na lição
Semana 4
Olá! Bem-vindo à Semana 4 do curso sobre TDD! Nesta semana você aprofundará seu contato teórico e prático com técnicas de refatoração. Ao final desta semana, você será capaz de identificar alguns dos principais tipos de mau cheiro e aplicar técnicas de refatoração apropriadas para remoção segura desses maus cheiros.
Conheça os instrutores
Clovis FernandesProfessor Titular in Portuguese
Ciência da Computação
Eduardo GuerraProfessor Colaborador
[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]
Explore nosso catálogo
Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.
O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.
© 2019 Coursera Inc. Todos os direitos reservados.
