Estudo de Caso

Sistema para Biblioteca Cadastro e Emprstimo

de Livros.
Padres: Prototype, Composite, State, Visitor, Template Method e Singleton.

Douglas Resende
Jlio Csar Pessoa
Leandro Medeiros
Maiki Perin
Maurcio Dangoni Antoniazzi
Vinccius Neves
Willian Moreira Gabriel

Prototype
1. Funcionalidade: Incluso de nova edio de livro.
2. Defesa:
Ao se solicitar a criao de um novo objeto Livro, que seja uma nova
edio de um livro j cadastrado, o sistema fornece a opo de criar novo
objeto aproveitando as caractersticas da verso anterior, como autor,
editora, titulo... Etc. A classe Cliente faz a solicitao de criao de um
novo livro classe Livro passando como parmetro o livro de edio
anterior e os novos parmetros pertencentes a este novo livro, como por
exemplo, ano, quantidade de captulos...etc. A classe Livro extende a
classe nativa Cloneable que oferece um mtodo genrico de cpia de
objetos, o objeto da classe Livro, requisita as cpias, com base nos
parmetros passados.
3.

Diagrama de Classe:

State e Singleton
1. Funcionalidade: Emprstimo de Livro
2. Defesa: O processo de Emprstimo de um Livro faz com que um objeto
desta classe tenha respostas diferentes, dependendo do seu estado
(Disponvel ou Emprestado). Por exemplo, invocando o mtodo solicitar
(reservar) de um objeto da classe Livro seu comportamento ser
diferente, se o Livro est no estado Disponvel ou no estado
Emprestado.
Para tratar esse fluxo vamos usar o padro state que
comportamental, ou seja, o livro pode ter dois estados e para cada
estado temos um objeto especifico, ento o Livro atravs da interface
do estado determina as aes, e os objetos concretos das classes
Disponvel e Emprestado implementam responsabilidades especiais
para esses estados, realizando essas aes de forma transparente ao
objeto Livro. A classe Livro mantm uma instncia de alguma subclasse
de EstadoLivro com o atributo estado que representa o estado atual do
Livro. Est instncia tem que ser nica, pois um livro deve possui
apenas um estado, Disponvel ou Emprestado, lembrando que cada
estado implementa responsabilidades especiais, e para garantir essa
caracterstica, as subclasses EstadoLivro implementam o padro
Singleton.
3. Diagrama de classe:

Exemplo Hipottico de execuo das funcionalidades:

Livro_Ed1 = new Livro("Padres de Projeto ", FulanoAutor,
2010);
Livro_Ed2 = Livro_Ed1 .clone();
Livro_Ed2.setAno(2012);
Livro_Ed1.solicitar(); // Disponvel -> Emprestado
Livro_Ed1.solicitar(); // Ops, o livro j est Emprestado
Livro_Ed1.devolver();
// Emprestado -> Disponvel
Livro_Ed2 devolver();
// nada, o livro j est disponvel
Livro_Ed2. solicitar();
// Disponvel -> Emprestado
Print Livro: + Livro_Ed1->toString();
Print Estado: + Livro_Ed1->estado;
Print Livro: + Livro_Ed2->toString();
Print Estado: + Livro_Ed2->estado;
Sadas:
Livro: Padres de Projeto, FulanoAutor,2010.
Estado: Disponvel

Livro: Padres de Projeto, FulanoAutor,2012.

Estado: Emprestado.

Com variveis de instncia nos estados, alocao dinmica uma soluo

simples. No entanto, na maioria das aplicaes de objetos para os Estados do
Estado-objetos
esto l apenas para fornecer um tipo nico e no precisa de todas as variveis
de instncia. Design Patterns descreve isso como "Se os objetos do Estado no
tm
variveis de instncia [...] ento contextos pode compartilhar um objeto de
Estado "[1]. na sua amostra padres de cdigo de design observa que este o
caso, apenas um
instncia de cada estado do objeto necessria, e com que motivao faz com
que cada estado um Singleton.
Depois da minha entrevista com o Sr. Singleton prometi explicar porque esta a
abstrao errado. A razo que a responsabilidade de administrar
estado-casos colocado no objeto errado, ou seja, o prprio Estado, e um
objeto no deve assumir nada melhor sobre o contexto em que
utilizado. Design Patterns descreve um caso particular em que apenas uma
instncia necessria. Essa necessidade, no entanto, no implica uma restrio
de exclusividade em
O Estado-objetos prprios que motivam a Singletons. Alm disso, se os Estados
devem ser compartilhados ou no deve ser decidido no contexto.
Obviamente, a abordagem Singleton quebra esta regra e, para todos os efeitos
prticos, obriga todos os estados a ser aptrida.

Para resumir, Singleton leva a:

1. uma abstrao errnea,
2. a complexidade do cdigo desnecessrio,
3. restries suprfluas singularidade,
4. e limita seriamente as capacidades de teste de unidade.
Claramente outra abordagem seria prefervel. 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 cdigo de
seus usurios aps atrasos do sistema de experincia e um profiler aponta para
o estado instanciao-