Estudo de CasoSistema para Biblioteca – Cadastro e Empréstimo de Livros.

Padrões: Prototype, Composite, State, Visitor, Template Method e Singleton.

Douglas ResendeJúlio César PessoaLeandro MedeirosMaiki PerinMaurício Dangoni AntoniazziVincícius NevesWillian Moreira Gabriel

Prototype1. Funcionalidade: Inclusão de nova edição de livro.

2. Defesa: Ao se solicitar a criação de um novo objeto Livro, que seja uma nova edição de um livro já cadastrado, o sistema fornece a opção de criar novo objeto aproveitando as características da versão anterior, como autor, editora, titulo... Etc. A classe Cliente faz a solicitação de criação de um novo livro à classe Livro passando como parâmetro o livro de edição anterior e os novos parâmetros pertencentes a este novo livro, como por exemplo, ano, quantidade de capítulos...etc. A classe Livro extende a classe nativa Cloneable que oferece um método genérico de cópia de objetos, o objeto da classe Livro, requisita as cópias, com base nos parâmetros passados.

3.Diagrama de Classe:

State e Singleton1. Funcionalidade: Empréstimo de Livro

2. Defesa: O processo de Empréstimo de um Livro faz com que um objeto desta classe tenha respostas diferentes, dependendo do seu estado (Disponível ou Emprestado). Por exemplo, invocando o método solicitar (reservar) de um objeto da classe Livro seu comportamento será diferente, se o Livro está no estado Disponível ou no estado Emprestado.

Para tratar esse fluxo vamos usar o padrão state que é comportamental, ou seja, o livro pode ter dois estados e para cada estado temos um objeto especifico, então o Livro através da interface do estado determina as ações, e os objetos concretos das classes Disponível e Emprestado implementam responsabilidades especiais para esses estados, realizando essas ações de forma transparente ao objeto Livro. A classe Livro mantém uma instância de alguma subclasse de EstadoLivro com o atributo estado que representa o estado atual do Livro. Está instância tem que ser única, pois um livro deve possui apenas um estado, Disponível ou Emprestado, lembrando que cada estado implementa responsabilidades especiais, e para garantir essa característica, as subclasses EstadoLivro implementam o padrão Singleton.

3. Diagrama de classe:

Exemplo Hipotético de execução das funcionalidades: Livro_Ed1 = new Livro("Padrões de Projeto ", “FulanoAutor”, ”2010”); Livro_Ed2 = Livro_Ed1 .clone(); Livro_Ed2.setAno(“2012”); Livro_Ed1.solicitar(); // Disponível -> Emprestado Livro_Ed1.solicitar(); // Ops, o livro já está Emprestado Livro_Ed1.devolver(); // Emprestado -> Disponível Livro_Ed2 devolver(); // nada, o livro já está disponível Livro_Ed2. solicitar(); // Disponível -> Emprestado

Print “Livro:” + Livro_Ed1->toString(); Print “Estado:” + Livro_Ed1->estado; Print “Livro:” + Livro_Ed2->toString(); Print “Estado:” + Livro_Ed2->estado; Saídas: Livro: Padrões de Projeto, FulanoAutor,2010. Estado: Disponível Livro: Padrões de Projeto, FulanoAutor,2012. Estado: Emprestado.

Com variáveis de instância nos estados, alocação dinâmica é uma solução simples. No entanto, na maioria das aplicações de objetos para os Estados do Estado-objetosestão lá apenas para fornecer um tipo único e não precisa de todas as variáveis de instância. Design Patterns descreve isso como "Se os objetos do Estado não têmvariáveis de instância [...] então contextos pode compartilhar um objeto de Estado "[1]. na sua amostra padrões de código de design observa que este é o caso, apenas uminstância de cada estado do objeto é necessária, e com que motivação faz com que cada estado um Singleton.Depois da minha entrevista com o Sr. Singleton prometi explicar porque esta é a abstração errado. A razão é que a responsabilidade de administrarestado-casos é colocado no objeto errado, ou seja, o próprio Estado, e um objeto não deve assumir nada melhor sobre o contexto em que éutilizado. Design Patterns descreve um caso particular em que apenas uma instância é necessária. Essa necessidade, no entanto, não implica uma restrição de exclusividade emO Estado-objetos próprios que motivam a Singletons. Além disso, se os Estados devem ser compartilhados ou não deve ser decidido no contexto.Obviamente, a abordagem Singleton quebra esta regra e, para todos os efeitos práticos, obriga todos os estados a ser apátrida.Para resumir, Singleton leva a:1. uma abstração errônea,2. a complexidade do código desnecessário,3. restrições supérfluas singularidade,4. e limita seriamente as capacidades de teste de unidade. Claramente outra abordagem seria preferível. No entanto, antes de compartilhar qualquer estado, eu gostaria de apontar para o conselho Josué Kerievsky de que "ésempre o melhor para adicionar um estado de compartilhamento de código de seus usuários após atrasos do sistema de experiência e um profiler aponta para o estado instanciação-