[MÚSICA] [MÚSICA] Meu nome é Eduardo Guerra. Esse é o curso de orientação a objetos com Java. Hoje eu vou estar falando para vocês sobre encapsulamento. Só que agora eu vou falar quando você tem objetos e arrays dentro da sua classe, para você entender alguns dos cuidados que você precisa ter quando você vai retornar esse tipo de informação para quem está do lado de fora. Vamos ver então? O que acontece? Uma classe, voltando aà o nosso exemplo da classe Atriz, a gente pode ter dentro da classe informações mais complexas, como arrays, como objeto. Então a gente tem o exemplo aÃ, por exemplo array de strings aà que guarda os prêmios da atriz e podemos ter por exemplo o amante, que é o ator, que é objeto. Então por exemplo o que que acontece? Se eu for lá e der o getPremios, eu vou receber aquele array de strings. Esse array de strings eu posso pegar e modificar ele. Por mais que eu não tenha setPremios que me permite setar ali array de prêmios, se eu posso receber ele e eu modificar, ele vai ser modificado dentro do objeto. Então por exemplo se eu pegar ali e colocar ali o "Framboesa de Ouro", o famoso "Razzie Awards" premia aà os piores do ano não é? Perto ali do Oscar que premia os melhores, o "Framboesa de Ouro" são os piores. Eu posso pegar e colocar ali o "Framboesa de Ouro" ali para o ator, sem que o objeto saiba disso, porque eu estou pegando o array, que está lá dentro do objeto. Eu estou modificando ele. Então com isso daà vai modificar dentro do objeto também. A mesma coisa funciona ali para objeto que esteja dentro do objeto. Então se eu der getAmante e recuperar o objeto ator e eu setar nome ali, o seu amante é o fulano agora, aquela informação do objeto, o objeto ator que eu estou modificando é o mesmo que está dentro do objeto. Então ele vai ser alterado lá também. Isso daà é uma quebra de encapsulamento. Porquê? Porque à s vezes o cara vai lá não é? Ele fala assim: " eu não vou permitir que altere o ator". Eu não vou permitir que altere o array de prêmios, ou que isso seja alterado somente de uma forma controlada. Mas o que acontece é que se você consegue recuperar e alterar as informações dele, não só você pode causar funcionamento errado como você está quebrando o encapsulamento que tinha sido planejado para aquela classe. E a gente já viu esse carinha aà numa outra aula. Ele olhou e falou assim: "puxa eu estou querendo modificar prêmio. Eu não sei jeito certo de fazer. Olha, se eu recuperar array eu posso mudar aqui. Eu estou querendo botar outro amante aqui para essa atriz. Olha, eu consigo alterar o nome do ator, dá para fazer isso, vai imprimir na tela do jeito que eu quero, por mais que eu não tenha alterado as outras informações". Não dá essa chance para o cara fazer besteira no seu software. Já falei isso antes num outro contexto, falo agora novamente. Para essa questão a gente tem duas soluções que a gente pode estar utilizando. Eu vou falar aà sobre cada uma delas. A primeira delas é você retornar clone, ou seja, você copia aquele objeto que está dentro da classe e retorna. E aà aquilo que for alterado não é o que está dentro do objeto. Então ele pode pegar, pode alterar à vontade que não vai ter efeito. Então por exemplo, imagina ali que no método getAtor, do getAmante quer dizer, eu crio novo objeto ator com todas as informações daquele objeto. Eu posso criar novo, copiar as informações, tem outras estratégias aà para clonar objetos, não é o escopo aqui da nossa aula. E aà dessa forma se a pessoa recuperar o ator e mudar o nome dele, isso não vai influenciar o objeto ator que está dentro da classe Atriz. Então ele pode alterar à vontade que isso não vai quebrar o encapsulamento e não vai alterar. A mesma coisa vale para os arrays, a gente tem alguns métodos na biblioteca do Java para cópia de arrays, aà eu usei o Arrays.copyOf. Então eu pego copio o array e retorno. Aà a pessoa pode fazer o que quiser com aquele array que vai ser array diferente daquele que está dentro da minha classe. Também não vai dar problema. A outra solução é você esconder o objeto, ou seja, você não retornar ele de forma nenhuma. E aà você fala assim: " mas como é que a pessoa vai ter acesso aquilo?" Você pode criar métodos que vão controlar o acesso sem retornar o objeto diretamente. Vamos ver como é que isso fica. Então por exemplo, ao invés de eu retornar, dá getAmante e retornar ator, eu posso ter por exemplo, getNomeAmante ou getIdadeAmante que seriam as informações ali do ator, que a pessoa de repente poderia recuperar para pegar. Só que eu faço isso retornando as informações direto e não retornando o objeto inteiro. No caso do array seria alguma coisa mais assim: ao invés de eu falar getPremios e receber o array, eu falaria getPremio e aà eu receberia, passaria como parâmetro o Ãndice do array que aà ele me retornaria aquela string especÃfica. Então dessa forma também eu não estaria expondo o array de forma a dar chance de eles poderem ser modificados de forma indevida pela pessoa. Então são essas duas alternativas que eu tenho, que é estar copiando o objeto antes de retornar e estar encapsulando completamente o acesso e nunca fazendo esse retorno. Então eu espero aà que com essa aula tenha sido possÃvel entender melhor essa questão do encapsulamento, principalmente quando a gente tem objetos e arrays dentro de outros objetos. Entender o que é que pode acontecer quando a gente retorna isso, considerar isso quando a gente está fazendo o design das classes. Quando eu comecei a falar de encapsulamento, eu falei que não é uma coisa que vem de graça, é uma coisa que a gente tem que projetar nossas classes, projetar o nosso software para que seja possÃvel ter este encapsulamento, esse encapsulamento ser real. Se você permitir que o cara pegue o objeto e modifique e o desenvolvedor perceber que isso é possÃvel, ele vai usar isso, ele vai quebrar o seu encapsulamento. Então muito cuidado. Aprendemos duas formas de resolver essa questão. Espero que tenham ficado, todos agora estejam cientes desse problema e saibam como resolvê-lo. Muito obrigado. Até à próxima aula. [MÚSICA]
