[MÚSICA] Meu nome é Eduardo Guerra. Você está aqui no curso de orientação a objetos com Java. Hoje vamos falar de assunto extremamente importante que é o relacionamento entre as classes tá? A ideia dessa aula é mostrar pouco para vocês, eu sei que a gente ainda não viu muito a questão prática né? A gente tá meio que dando os primeiros passos Java, mas a minha ideia aqui é mostrar para vocês a ideia real de orientação a objetos que é você combinar várias classes para criar uma funcionalidade de sistema. Bom, para mostrar isso para vocês, vim aqui nesse deserto aqui, nesse calor. Nossa! Para mostrar para vocês o quê? Essa pedra! Porque é que eu vim aqui mostrar para vocês essa pedra? Para que vocês não façam o sistema de vocês dessa forma, certo? Muita gente às vezes quando programa, programação estruturada com funções, faz o programa é aquele blocão, é aquela coisa enorme que é bloco só. Então assim quando a gente está trabalhando com orientação a objetos, a gente tem que fugir dessa pedra, a gente não tem que querer que o nosso software não tenha a cara dessa pedra, porquê? A pedra, se a gente precisar diminuir pedacinho, se a gente precisar modificar alguma coisa por exemplo imagina lá dentro dela, a gente tem que mexer na pedra inteira, a gente tem que destruir a pedra inteira. E não é isso que a gente quer, a gente quer sistema que seja fácil de trabalhar, fácil de mexer, fácil de manter tá? Então aí a gente vem aqui com o que a gente tem que buscar que é peças né? O mais conhecido aí como Lego né? Certo? A gente tem que tentar fazer o nosso sistema dessa forma, né? Como se fossem várias pequenas peças. Porquê? Porque se a gente precisar mudar uma, uma peça a gente só tira ela e coloca outra, mesmo que ela esteja no meio de uma grande estrutura, a gente não precisa mexer todas né? Às vezes uma peça que a gente faz, a gente pode usar aquela mesma peça que a gente construiu, que seria digamos assim o formato da peça seria mais ou menos a classe, né? A gente pega aquela classe e instancia vários objetos né? Ás vezes com cores diferentes para montar aquele sistema maior. Então é, é essa ideia que a gente tem que perseguir tá certo? Então as classes de sistema elas têm que colaborar de forma a chegar naquela funcionalidade que você quer certo? Você não pode pensar numa funcionalidade como uma coisa que vai estar inteira dentro de uma classe ou inteira dentro de método do seu sistema. Você tem que pegar as responsabilidades e tentar dividir essas responsabilidades. Imagina por exemplo, para a gente entender esses conceitos que eu estou falando, imagina que a gente esteja desenvolvendo sistema de uma pizzaria online, que o preço da pizza vai depender aí dos ingredientes dela, como a maioria das pizzarias trabalha dessa forma e a entrega depende aí do, o valor da entrega depende do dia da semana, depende da distância entre a casa da pessoa, onde vai ter que entregar e a pizzaria. Nem passe pela sua cabeça querer fazer esse sistema como uma pedra tá? Querer colocar todas essas funcionalidades, todos esses cálculos dentro de método só que fala: se tem ingrediente tal bota isso, se tem o outro ingrediente, se tem calabresa coloca aquilo, se o cara mora a tanto de distância bota mais, mas se for na segunda-feira é de graça. Então nem pense querer botar isso tudo no mesmo local tá? Então vamos tentar a partir desse exemplo, chegar quais classes a gente utilizaria e como elas vão colaborar para formar essa funcionalidade. O que é que a gente pode ter no sistema? A gente teria aqui a própria classe pizza, que seria responsável ali por estar calculando o preço baseado nos ingredientes, poderíamos ter uma classe entrega, que estaria ali responsável por calcular o valor do frete, e a gente teria uma classe aí que seria o carrinho de compras, que é uma metáfora muito comum principalmente quando a gente trabalha com e-commerce, que seria onde por exemplo normalmente, muitas vezes a pessoa vai comprar, ela não compra uma pizza só, ela compra às vezes várias pizzas, compra ali refrigerante, pode comprar uma sobremesa. Então esse carrinho seria onde teriam todos os produtos que a pessoa comprou né? E também quando eu perguntasse o total desse carrinho, ele me daria o somatório do preço dos produtos mais o preço da entrega, que seria aí o preço total. Como que essas classes vão colaborar? Eu teria por exemplo, o carrinho sabendo calcular o preço total, o carrinho por exemplo ele ia cada produto dele, se fosse uma pizza ele perguntaria para essa pizza: pizza qual é o seu preço? E aí o carrinho, paro o carrinho não interessa como que a pizza calcula o total dela. Isso é responsabilidade da pizza. A responsabilidade do carrinho é somar o preço de seus produtos com o preço da entrega. O calcular o preço da pizza com base nos seus ingredientes é responsabilidade da classe pizza. Então a classe carrinho pra poder dizer o valor total, ele ia colaborar com a classe pizza e perguntar: classe pizza, na verdade o objeto pizza, objeto pizza qual que é o seu valor? E aí ele simplesmente ia pegar aquele resultado pra somar com o resto. E a mesma coisa com a classe entrega, que seria responsável de calcular esse valor da entrega da pizza. Então a classe carrinho ia colaborar com a classe entrega, ia colaborar com a classe pizza, para criar toda essa funcionalidade que é poder dizer qual que é o valor total da compra. Então o carrinho ele iria lá para cada dos itens, perguntando o valor, de repente se fosse uma, refrigerante ele já teria valor fixo né? No caso da pizza ele teria uma lógica interna pra retornar esse valor, e a entrega ele ia pegar por exemplo o endereço e ia pegar o dia da semana e teria também uma lógica interna pra fazer isso. Dessa forma fica muito claro que se por exemplo, eu tiver ingrediente novo na minha pizzaria, eu posso modificar somente a classe pizza e a classe carrinho não tem que saber nada disso. Tá? Da mesma forma se eu quiser fazer uma promoção de que, sei lá, às quartas-feiras a entrega é gratuita ou tem certo desconto, também a classe carrinho e a classe pizza não precisariam estar envolvido nisso. Então essa é uma das vantagens de eu estar tentando separar as responsabilidades do meu sistema. Eu consigo dividir o que cada faz e depois quando eu vou fazer a modificação uma parte, aquilo ali não afeta o resto. E aí com isso, a gente dá para perceber que sistema orientado a objeto, ele é basicamente identificar quais são as peças e como elas vão se encaixar. Tá? Então qual que foi o meu esforço nesse caso aqui da pizzaria? É descobrir quais eram as classes que estavam envolvidas na criação desse sistema da pizzaria no caso a pizza, a entrega, né? A gente viu aí outras aulas como identificar isso aí, como ver essas colaborações né? E o grande segredo da modelagem orientada a objetos é justamente você identificar quais são essas peças e como é que elas vão colaborar para criar aquela funcionalidade final do seu sistema. Com isso a gente viu aí, entendeu melhor o relacionamento entre as classes e como que a gente pode combinar funcionalidades diferentes, classes de objetos para criar a funcionalidade geral do sistema. Até à próxima aula. [MÚSICA]
