[MÚSICA] [MÚSICA] Olá, bem vindo ao curso de orientação a objetos com Java. Hoje iremos dar continuidade à Modelagem CRC explicando pouquinho melhor o passo 6. No passo 6 nós revisitamos todas as responsabilidades das classes identificadas, vamos apresentando lógicas para cada uma delas e ao apresentar essas lógicas, eventualmente, surge alguma necessidade de alguma colaboração e aà nós examinamos se essa colaboração precisa de, pode ser feita por alguma das classes já existentes, se não nós criamos uma classe nova para ela. E assim a gente vai desenvolvendo à medida que novos requisitos vão aparecendo, aà é desse jeito que a gente vai fazer. Vamos exemplificar esse refinamento através da classe Livro. Nós temos algumas responsabilidades na classe Livro e examinaremos então como a lógica delas pode ser realizada e isso pode resultar refinamentos. Por exemplo, conforme está representado aà nas transparências através do número 1, vamos examinar a classe Livro. Nós temos por exemplo, a responsabilidade "Sabe disponibilidade do livro". Isso pode ser representado por atributo simples, booleano e você pode representar por verdadeiro ou falso. Então se for verdadeiro o livro está disponÃvel, se for falso o livro não está disponÃvel. Para isso, como a gente pode ver aà no número 1, está relacionado com o "Marca livro como emprestado". A lógica do marcar o livro como emprestado, simplesmente vai lá nesse atributo, nessa variável de instância emprestado e transforma ele falso por exemplo. Mas a gente pode ver na sequência número 2, quando eu marco o livro como disponÃvel para empréstimo, ele simplesmente vai lá na lógica dessa responsabilidade aÃ, na variável disponibilidade e transforma ela verdadeiro. Então a "Marca disponÃvel", "Marca o livro como emprestado" torna ela falsa, o "Marca o livro como disponÃvel" torna ele verdadeiro. Isso é uma maneira de realizar. Você está vendo aà pelo número 3, nós estamos relacionando o "Sabe disponibilidade empréstimo" com a responsabilidade "Sabe usuário". Vamos examinar a "Sabe usuário". A "Sabe usuário", eu simplesmente posso ter uma variável usuário do tipo Usuário, que no momento que usuário empresta livro, eu uso o "Anexa usuário" não é? E armazeno o objeto Usuário de quem acabou de emprestar o livro nessa variável usuário. O consequente? Se eu olhar e perguntar se essa variável é nula ou não, e se ela for nula, significa que o livro está disponÃvel ainda, se não for nula o livro já foi emprestado. Para quem? Para o usuário que foi armazenado nessa variável. Eu poderia então, vez de marcar que o livro está emprestado usando a variável disponibilidade, eu poderia usar a usuário. Ao fazer isso eu posso eliminar o "Marca livro como emprestado". Aà no ponto 4 eu estou fazendo essa relação. Se eu fizer o armazenamento usando o "Marca livro como emprestado" e usando o usuário, eu iria marcar o usuário ali, quando o livro fosse emprestado. Então eu marco lá o usuário. Mas eu tenho a "Anexa usuário", que já faz isso. Se a "Anexa usuário" já faz isso, para que é que eu vou usar a "Marca livro como emprestado"? Eu já uso o "Anexa usuário", ele passa a cumprir duas finalidades. Ele anexa o usuário e ao anexar o usuário, ele já está me dizendo "o livro é indisponÃvel". O usuário já está com o objeto Usuário de quem emprestou o livro. Com isso a "Marca o livro emprestado" já não faz sentido aparecer. Da mesma forma, "Marca livro disponÃvel" marca ali o usuário quando o livro se torna disponÃvel, ele tornaria o usuário que teria, o usuário anterior que tinha emprestado o livro, marca como nulo, de forma que a disponibilidade, saber a disponibilidade agora fica simples também. Basta olhar o usuário e fica sabendo que o livro está disponÃvel. É, mas eu tenho o "Desanexa usuário". Essa responsabilidade faz a mesma coisa. Então novamente, eu posso eliminar o "Marca livro como disponÃvel", porque faz mais sentido eu manter a "Anexa usuário", porque desanexar o usuário automaticamente significa que a variável usuário vai ficar nula e o livro está disponÃvel. Então fica assim, muito mais fácil eliminar o "Desmarca livro disponÃvel". Com isso a classe Livro fica com apenas duas responsabilidades do tipo "faz". Nós eliminamos o "Marca livro emprestado " e o "Marca livro disponÃvel" mas isso tem consequências outros lugares. Eu estou tirando essas responsabilidades de Livro, as duas eram colaborações de responsabilidades de Biblioteca. Por exemplo o "Empresta livro" de Biblioteca. Vamos dar uma olhada então no "Empresta livro" de Biblioteca? No "Empresta livro" de Biblioteca anteriormente pela minha lógica do "Empresta livro", eu marcava o livro como emprestado. Cara, mas agora isso já é feito pelo, pela responsabilidade colaboradora do próprio livro, que é o "Anexa usuário" que emprestou o livro. Então eu já posso eliminar. E é o que eu faço. Já a outra responsabilidade "Devolve livro", também fazia uso da colaboração de "Marca livro disponÃvel" de Livro, mas o "Desanexa usuário de livro emprestado" já está cumprindo esse papel. Então eu também elimino do "Devolve livro" o "Marca livro disponÃvel". Com isso a responsabilidade "Empresta livro" fica apenas com duas responsabilidades do tipo "faz". Resumindo tudo isso agora, essas mudanças, esses refinamentos que nós fizemos, no cartão CRC de Biblioteca, fica registrado que a responsabilidade "Empresta livro" agora só tem o "Anexa usuário" e o "Desanexa usuário" como colaborações. O cartão CRC de Livro tem apenas duas responsabilidades do tipo "faz": o "Anexa usuário do empréstimo" e "Desanexa usuário do empréstimo". Só isso. A classe Usuário, ela continua do jeito que estava, não houve mudança relação à anterior. O diagrama de colaboração na essência continua o mesmo, mas no particular, no detalhe houve mudança, porque antes havia colaboração do "Marca livro emprestado" e "Marca livro disponÃvel", que eram responsabilidades de Livro, que foram eliminados por causa da redundância ao se estudar maneiras de organizar melhor as lógicas das responsabilidades de Livro. Então houve uma diminuição na dependência da classe Biblioteca relação à classe Livro. Não houve mudança nenhuma relação, da classe Biblioteca relação à classe Usuário. Todo esse processo mostrando UML continua igual, que a gente só está mostrando alto nÃvel. Nós mostramos que a Modelagem CRC, ela tem particularidades que podem ajudar a remover redundâncias. Eu posso, ao analisar com mais detalhe as questões de responsabilidade do tipo "sabe" com responsabilidade do tipo "faz" e isso pode ter cosequências, que no nosso exemplo, o sistema de automação da biblioteca, implicou na diminuição de responsabilidade, na diminuição do grau de dependência de Biblioteca, da classe Biblioteca com relação à classe Livro. Mas esse processo todo à s vezes pode implicar ter mais responsabilidades, até na criação de novas classes caso apareçam nas lógicas responsabilidades novas que impliquem classes novas também. Isso tudo vai depender, esse é processo dinâmico das mudanças de requisitos, de introduzir novos requisitos ou da maneira de trabalhar a questão da coesão dentro das classes, que foi o que nós fizemos com a classe Livro por exemplo. Até a próxima aula.
