[MÚSICA] [MÚSICA] Olá, bem vindo ao curso de orientação a objetos com Java. Eu sou o Clovis Fernandes e hoje iremos falar de acoplamento. Na aula de hoje iremos caracterizar o conceito de acoplamento e vamos exemplificar duas situações de acoplamento alto. Na próxima aula iremos mostrar como transformar esse acoplamento alto que é uma coisa não muito boa, não é nada boa para o projeto da nossa aplicação, numa de acoplamento baixo que é muito bom para o que a gente está querendo. Como eu ia dizendo então nós vamos caracterizar o conceito de acoplamento. Nós temos acoplamento bom, que é acoplamento baixo, e acoplamento ruim, que é acoplamento alto. E caracterizar dois exemplos de situações que caracterizam o acoplamento alto. O que que é então acoplamento? Acoplamento descreve os relacionamentos e as dependências entre classes. No fundo ela dá o grau de interconexão, de interdependência de uma classe relação às outras. Isso é o acoplamento. Para o nosso trabalho, basta caracterizar 2 tipos de acoplamento: acoplamento baixo e acoplamento alto. No acoplamento alto, como vocês estão vendo nessa figura, eu tenho muitas conexões de uma classe com outra, eu tenho dependências de uma classe e outras. Na verdade eu posso ter até entre várias classes com outra classe ou várias classes com várias outras classes. E quanto maior o grau de acoplamento, mais difícil fica para você fazer alguma mudança. O seu aplicativo fica difícil de desenvolver, não fica flexível para mudanças, então não é uma coisa boa. Então nós podemos colocar esse carimbo de bad, ruim para acoplamento alto, porque fica difícil de desenvolver, modificar, reusar, aperfeiçoar o sistema com novos requisitos. Contrapartida acoplamento baixo que você reduz ao mínimo as interconexões entre as classes e as outras classes, você reduz isso ao mínimo, isso é bom porque ao contrário do acoplamento alto, quanto menos acoplamento menos problemas você tem. Se no caso de acoplamento alto você mudasse uma determinada classe da qual muitas outras classes dependem, qualquer mudança é muito trabalhosa. Já com o acoplamento baixo, com poucas dependências de uma classe relação à outra, as mudanças ficam mais fáceis de serem executadas. Por isso que o acoplamento baixo é bom e a gente então vai carimbar acoplamento baixo como uma coisa boa. É o que nós queremos, é o nosso alvo. Contudo dependendo da maneira como você projeta o seu sistema, você pode inicialmente não alcançar esse acoplamento baixo. Então você vai ter que fazer algum tipo de refatoração, de remodelar o que você fez para diminuir o acoplamento entre as classes da sua aplicação, ou então você já pode aplicar alguns princípios que vão conduzir você a ter no final, classes com menos acoplamento, com acoplamento baixo. Então esse é o ideal. A seguir eu vou mostrar duas situações de acoplamento muito ruim. São os piores tipos de acoplamento. Então é acoplamento alto, mas é do pior grau. Significa que nós precisamos tomar muito cuidado com ele. Nós podemos na verdade evitar à priori, para não cair nisso na hora que estamos iniciando ou começando a fazer o nosso projeto. Compensação se nós cairmos nisso, existem maneiras como eu vou mostrar na próxima aula, de reverter isso com facilidade. Embora o ideal é já produzir sem esse tipo de acoplamento. O primeiro tipo de acoplamento que eu vou mostrar é o acoplamento com dados internos. No acoplamento com dados internos os dados são expostos, eles estão públicos. Por isso que a gente deixa as variáveis de instância, define por convenção como privadas para não acontecer isso. Então aqui normalmente vocês já não vão produzir isso, mas é só para exemplificar, já estar definindo que ela não é uma coisa boa. Eu estou carimbando, olha os dados delas são públicos, porque eu estou expondo os dados ao acesso público. É como se eu estivesse expondo a minha carteira de dinheiro, alguém pode vir enfiar a mão no meu bolso, tirar o dinheiro e eu não posso reclamar porque eu permiti isso, eu estou deixando os meus dados internos expostos. No exemplo 1 eu vou mostrar através, num diagrama de classes e partes de código, que uma classe A acessa os dados internos da classe B. Esses dados são o estado da classe B, de objetos da classe B. A classe A depende da classe B. A classe B, ela tem dado interno x que está público, é dado público, ele tem maisinho aí, então ele é público. A classe A pode acessar esse dado. No caso a classe A, chamando de método para simplificar, ela pretende incrementar o valor de x, o valor x de B de 1, ou seja, ela quer obter o sucessor do valor de B. Como o dado x é acessível, está público, basta eu instanciar uma classe. Então eu instanciei uma classe com objeto, instanciei a classe, criei objeto da classe B, eu coloquei no bezinho. Para acessar o campo a variável de instância x, basta eu colocar b.x. Se eu quero incrementar esse valor, eu pego o valor anterior do b.x somo com 1 e atribuo ao b.x. É como se eu pudesse então enfiar a mão na carteira de outra pessoa, tiro de lá o quanto ela tem de dinheiro, coloco valor de real a mais e devolvo a carteira. Nesse caso a pessoa vai gostar, mas se eu fizer a operação contrária de retirar dinheiro ela não vai gostar. Então a operação que na vida real não é uma coisa boa, isso que nós estamos fazendo também não é bom, isso é mau. Na figura da classe B eu identifico com círculo e uma seta essa variável que está exposta. Na classe A eu estou expondo o código do método, que eu defino essa operação que eu quero fazer. Então eu estou acessando uma variável que não deveria acessar. Então o que é que está acontecendo? O dado x, ele é público, ele está totalmente exposto. Eu posso ir lá e fazer o que eu quiser com ele, eu posso aumentar, diminuir, fazer o que eu quiser como eu fiz aí que foi simplesmente usar sucessor. O que é que eu estou, o que é que está ocorrendo ao expor o dado? Eu quebro o princípio de encapsulamento. O princípio de encapsulamento diz que eu só devo acessar as variáveis de instância dos objetos da minha classe através de métodos. Então o encapsulamento está tentando proteger, fazer com que eu não acesse esses valores. Para isso por convenção, a gente torna os dados privados e vamos colocar algum acesso. Que ideia é que a gente pode fazer inicialmente? Usar getter e setter por exemplo. A segunda situação que eu vou mostrar, fazer o acesso tentando, entre aspas, garantir o encapsulamento que vou usar métodos públicos da classe B, que vão acessar por mim o dado x, a variável de instância x. Eu vou mostrar para vocês que isso embora aparentemente não esteja quebrando o encapsulamento, no final das contas o encapsulamento continua sendo quebrado. Por que é que continua sendo quebrado? Porque os dados, os dados agora vez de serem públicos, eles são expostos publicamente de uma forma indireta através do setter. Então a gente carimba isso como sendo "Dados Expostos". De qualquer maneira ele é equivalente ao dado ser público. Não está me ajudando nada. Por que é que não me ajuda nada? Vamos ver no diagrama. A classe A, no diagrama que eu vou mostrar, acessa o dado que é o estado, do meu objeto por meio de getter e setter não é? Vocês percebam que na classe B agora a variável instância x é privada. Se ela é privada, o sinal é- por convenção na UML, então o sinal é menos, está indicando isso. E agora eu tenho getX público, mais também, set para obter o valor de X e setX com o parâmetro valor para alterar o valor de X. O setX também é público. Eu estou indicando agora, na classe A, vocês percebem pelas setas. Eu estou fazendo agora acesso à dependência agora que eu tenho não é do dado direto. É dado que vai ser exposto por get e set. Então vou agora fazer esse meu sucessor do valor lá do objeto da classe B. Eu vou fazer usando o get e o set, então eu ponho b.setX vou passar o parâmetro, o parâmetro era obter o valor de X através de b.getX e acrescentar de 1 para obter o seu sucessor. E aí ele é parâmetro do b.setX. Eu vou então colocar o nome no valor. Então, aparentemente, tudo está correndo bem. Parece orientado a objetos, mas não está sendo bem orientado a objetos, porque eu estou tendo acoplamento desnecessário, eu posso resolver isso, eliminar esse tipo de acoplamento. Novamente os dados estão expostos, então eu estou carimbando isso aí. Dados expostos! E se os dados estão expostos é equivalente a eu ter, usando o getter e setter é equivalente ao uso direto dos dados internos de forma pública. Isso não é uma coisa boa, embora esteja usando métodos de acesso, eu ainda assim estou quebrando o encapsulamento, porque ele é idêntico ao dado ser público. Nós veremos outras aulas no nosso curso que os getter e setters têm seu papel, têm seu uso, mas nesse caso que nós estamos mostrando, nós podemos evitar facilmente e eu vou mostrar isso na próxima aula. Então, normalmente, os getter e setters eles poucas situações, eles podem ser públicos. Na maioria das vezes eles vão ser ou protegidos, que eles podem ser herdados por objetos de subclasse ou privados, que não vão poder algumas situações vão ser públicos. Mas quando nós podemos evitar isso, como é o caso desse, nós temos que evitar, porque ele fica equivalente pior tipo de acoplamento alto que é o de acesso a dados internos de uma classe. Então, concluindo, acoplamento alto, muito ruim. Carimbamos que ele é muito ruim. Devemos evitar ao máximo e nós vamos mostrar algumas técnicas para evitar isso já na próxima aula e nas aulas seguintes, nós vamos mostrar algumas técnicas de desenvolvimento que vão ajudar a minimizar os acoplamentos, fazendo com que vez de ter acoplamento alto com problemas de encapsulamento, nós tenhamos acoplamento baixo. Outra coisa que nós concluímos hoje que o acoplamento com dados internos da classe é alto, é o pior dos tipos de acoplamentos e o acoplamento com o uso de getter e setter é tão ruim quanto neste tipo de situação que eu estou mostrando aqui para vocês. Quando ele equivalem a expor dados como se fossem dados internos apenas tão somente. E vai ser uma [INAUDÍVEL] a gente mostrar como resolver isso de uma maneira simples. Então nessa aula identificamos acoplamento alto, aproveitamos para caracterizar acoplamento, o conceito de acoplamento. Falamos pouco de encapsulamento, que também é outro princípio que define que quando você vai, os acessos a dados internos são sempre através de métodos definidos na interface da classe só que essa definição de encapsulamento não foi suficiente a nos resguardar do uso inadequado da situação de hoje que usamos getter e setter. Com isso, nós tivemos uma coisa muito ruim também, que é o acoplamento alto, usando o getter e setter. A conclusão disso é os vários princípios devem ser combinados e é isso que eu vou mostrar na próxima aula, que nós vamos combinar vários princípios para melhorar o grau de acoplamento. No fundo, nós vamos baixar o acoplamento. Acoplamento baixo é o que é bom para a gente. Carimbo de bom para a gente. Até à próxima aula. [MÚSICA]
