Baixe o app para aproveitar ainda mais
Prévia do material em texto
Padrões de projeto de software Aula 9: Padrões GRASP básicos Apresentação Nesta aula, veri�caremos três padrões de projeto do tipo General Responsibility and Assignment Software Patterns (GRASP): Information Expert (em português, especialista na informação), Creator (criador) e Low Coupling (acoplamento fraco). O GRASP é composto de nove padrões amplamente aplicados de forma intuitiva pelos projetistas de software por eles estarem altamente relacionados ao bom senso da concepção de objetos. Os três abordados nesta aula, portanto, descrevem os princípios fundamentais da atribuição de responsabilidades a objetos. Objetivos Descrever as características do Information Expert; Esclarecer a natureza do Creator; Classi�car as qualidades do Low Coupling. Primeiras palavras Os padrões Information Expert, Creator e Low Coupling foram desenvolvidos para explorar princípios da teoria de orientação a objetos. O principal objetivo de um padrão de design é guiar o desenvolvedor na construção de componentes robustos, extensíveis e reutilizáveis. Para conseguir isso, ele endossa a luta contra os riscos presentes nas atividades de desenvolvimento de software orientados a objetos. Autor: TippaPatt (Fonte: Shutterstock). Information Expert Os padrões GRASP são muito úteis na construção de três tipos de diagrama: 1 De classes; 2 De sequência; 3 De colaboração. > Padrões GRASP Padrões básicos Padrões avançados Information Expert Polymorphism Creator Pure Fabrication High Cohesion Indirection Low Coupling Protected Variations Controller As responsabilidades de um objeto estão relacionadas às obrigações que ele tem quanto a seu comportamento. Exemplo Fazer um cálculo; criar um objeto; iniciar ações, controlar e coordenar ações em outros objetos; e responsabilidade de conhecer alguma coisa, como objetos relacionados a ele, dados privados e encapsulados e dados e/ou atributos que podem ser derivados ou calculados. As responsabilidades da classe não devem ser confundidas com os métodos dela, que são construídos para satisfazer às responsabilidades, as quais, por sua vez, são implementadas usando um ou vários métodos para realizar alguma função útil no sistema. 1. Objetivo A ideia principal deste padrão é atribuir uma responsabilidade para a classe que tem a informação necessária para satisfazê-la. Há uma grande complexidade nas especi�cações dos produtos de software graças às responsabilidades das classes nos sistemas orientados a objetos. Isso ocorre devido à grande quantidade de classes (centenas ou milhares) que deve receber tais responsabilidades. Em outras palavras, “os objetos fazem coisas relacionadas com as informações que possuem g”. (LARMAN, 2004) 2. Problema Qual é o princípio geral para a atribuição de responsabilidades aos objetos? Qual classe deve ter a responsabilidade de implementar um determinado método? Durante o design, quando são de�nidas as interações entre objetos, fazemos escolhas sobre a atribuição de responsabilidades às classes. Nesse momento, temos de escolher qual delas deverá implementar um método. Se boas escolhas forem feitas, os sistemas se tornarão mais fáceis de compreender, manter e estender, além de haver a possibilidade de reutilização de componentes em futuras aplicações. O princípio deste padrão é atribuir essa responsabilidade à classe que possui a informação necessária para cumprir a tarefa. Tal classe é considerada a especialista na informação (information expert). 3. Estrutura Para implementar o padrão Information Expert, é necessário identi�car a que classes devemos atribuir determinadas responsabilidades do sistema. Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online Exemplo Um sistema de vendas possui as seguintes classes com os respectivos atributos: venda: código da venda, data da venda, impostos e descontos; item de venda: código do item de produto vendido, quantidade e valor; e produto: código e descrição do produto. Qual classe deve ter a responsabilidade de saber o total da venda? Ou seja, qual dessas classes deve armazenar o atributo contendo a informação desse total? Nesse caso, a classe Venda deve assumir a responsabilidade, pois Item de venda conhece apenas o valor de cada item vendido, mas não possui as informações sobre descontos ou impostos da venda. Ela deve informar o somatório dos valores dos itens vendidos para a classe Venda calcular o valor total da venda com impostos e descontos possíveis. Os benefícios de Information Expert são os seguintes: O padrão possui baixo acoplamento entre os objetos na medida em que mantém o encapsulamento de informações dentro das classes que têm a responsabilidade de utilizá-las, pois os objetos usam a própria informação para cumprir suas responsabilidades ou enviam mensagens para as outras classes colaboradoras a �m de obter as informações de que necessitam; Caso seja necessário que várias classes trabalhem em conjunto para cumprir uma determinada responsabilidade devido à tarefa ser complexa, esse esforço �cará distribuído entre elas, favorecendo a alta coesão. 4. Dicas Este princípio personi�ca objetos. Entidades como produtos ou até conceitos como vendas podem ter responsabilidades. A atribuição de uma responsabilidade aos objetos muitas vezes não tem similaridade com aquela realizada no mundo real. Exemplo No mundo real, uma venda não calcula o próprio total. Isso é feito por uma pessoa. 5. Exemplo Em um sistema de biblioteca, qual classe deve ter a responsabilidade de realizar o cálculo da devolução da cópia de um livro que será emprestado? Classes do modelo OO do sistema com seus respectivos atributos: Reserva: Período e situação da reserva; Atendente: Nome do atendente; Leitor: Nome e tipo do leitor (aluno de graduação, pós-graduação); Empréstimo: Data e situação do empréstimo; Livro: Atributos de título, autor, nome do livro, ISBN, editora e ano; Bibliotecária: Nome da bibliotecária; Cópia do Livro: Situação do livro e status de liberação para empréstimo; Devolução: Data da devolução do livro e prevista da devolução. Atividade Em um sistema de biblioteca, qual classe deve ter a responsabilidade de realizar o cálculo da devolução da cópia de um livro que será emprestado? Classes do modelo OO do sistema com seus respectivos atributos: Reserva: Período e situação da reserva; Atendente: Nome do atendente; Leitor: Nome e tipo do leitor (aluno de graduação, pós-graduação); Empréstimo: Data e situação do empréstimo; Livro: Atributos de título, autor, nome do livro, ISBN, editora e ano; Bibliotecária: Nome da bibliotecária; Cópia do Livro: Situação do livro e status de liberação para empréstimo; Devolução: Data da devolução do livro e prevista da devolução. Padrões e princípios relacionados: Low Coupling; High Cohesion. Creator 1. Objetivos Identi�car as situações em que uma classe deve criar objetos de outra. O padrão Criador organiza a atribuição de responsabilidades relacionadas com a criação de objetos de software. Seu objetivo é de�nir um objeto criador que deva ser conectado ao objeto criado em qualquer momento da execução. A seleção do objeto criador deve garantir um fraco acoplamento e uma alta coesão entre os objetos do sistema. 2. Problema Qual classe deve ser responsável pela criação de uma nova instância de outra classe? Em um sistema OO, a tarefa de criar objetos é umas das mais comuns. Dessa forma, a existência de um padrão que de�ne regras para a atribuição de responsabilidades de criação é bastante útil. Os benefícios esperados para o sistema são: Acoplamento fraco; Mais clareza; Encapsulamento; Reutilização; Existem algumas condições para uma classe poder criar instâncias (objetos) em outra a �m de cumprir responsabilidades relacionadas a uma classe ou um grupo delas. A classe criadora: A de�nição de um princípio para a atribuição de responsabilidades de criação de objetos em um sistema orientado a objetos é muito útil, pois o processo de criação de objetos é uma atividade bastante comum. Sendo bem realizada,ela possibilitará ao sistema apresentar os benefícios descritos anteriormente (acoplamento fraco, mais clareza, encapsulamento e reutilização). Contém ou agrega objetos da outra classe; Registra instâncias da outra; Usa muitos objetos da outra; Possui dados que serão usados na iniciação e repassados ao construtor da outra. 3. Estrutura A seguir, descrevemos o procedimento de investigação necessário para descobrir qual classe seria a candidata a ser a classe criadora de um objeto A em outra relacionada: Verificamos se o objeto A faz parte de um relacionamento todo-parte. Nesse caso, normalmente o todo é o responsável pela criação de A quando outro objeto tem uma associação de um-para-muitos, em que A é o lado muitos; Investigamos se o objeto A está associado ao objeto de controle; Vemos se alguma classe tem dados necessários para a iniciação do objeto A. 5. Contraindicações Em alguns casos, o processo de criação de objetos é uma tarefa complexa. Isso ocorre quando ele: Outra situação em que não se deve usar o Creator é quando o processo de criação de objetos torna-se uma tarefa complexa, exigindo otimizações para a melhoria do desempenho do sistema e, eventualmente, criando uma instância de uma família de classes similares com base no valor de alguma propriedade externa – e assim por diante. Nesses casos, é aconselhável delegar a criação para uma classe auxiliar chamada Fábrica (Factory Method) em vez de usar o padrão Creator. Exige o uso de instâncias recicladas por motivos de desempenho; Cria uma instância de uma família de classes similares com base no valor de alguma propriedade externa. Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online 6. Exemplo Vamos apresentar agora um exemplo das funções de um sistema de PDV: Pedido de um estabelecimento que registra as vendas; Cada venda é de um ou mais itens de um ou mais tipos de produto, acontecendo em uma determinada data; Um produto tem uma especi�cação, incluindo descrição, preço unitário e identi�cador; O aplicativo também registra pagamentos (digamos, em dinheiro) associados a vendas; O pagamento é para um determinado valor igual ou maior que o total da venda. Nesse caso, quem deve ser o responsável pela criação de uma instância da classe ItemVenda? Utilizando os princípios do padrão Creator, devemos procurar pela classe que agrega, contém ou usa os objetos ItemVenda. Como a classe Venda contém (de fato, agrega) muitos objetos ItemVenda, ela, pelo padrão Creator, é uma boa candidata para receber a responsabilidade de criar as instâncias de ItemVenda. Exemplo de codi�cação em Java: class Sale { List< SalesLineItem > salesLineItem = new ArrayList< SalesLineItem >(); public void addLineItem(ProductSpeci�cation prodSpec,int quantity) { salesLineItem.add(new SalesLineItem(prodSpec, quantity); return salesLineItem; } } Padrões e princípios relacionados: Low Coupling; Factory Method. Atividade 2 - Em um sistema de Ponto de Venda (PDV), qual classe deve ter a responsabilidade de criar objetos de itens de venda? Alternativas: A classe Venda; A classe Itens de Venda; A classe Produtos. Classes do modelo OO do sistema com seus respectivos atributos: Classe Venda: Data da venda, Hora da venda; Classe Itens da Venda: Quantidade vendida, código do produto vendido; Classe Produtos: Código do item, descrição do item, preço. Low Coupling Esta classe é mais: O acoplamento é uma medida sobre quão fortemente uma classe está conectada a outras, tem conhecimento ou depende delas. Uma classe com baixo (fraco) acoplamento não depende de muitas outras. Ao contrário, uma com forte acoplamento apresenta alguns problemas. Difícil de compreender; Complicada de utilizar; Influenciada por mudanças nas classes que se relacionam com ela. 1. Objetivos Atribuir uma responsabilidade às classes do sistema de maneira que o acoplamento entre elas permaneça fraco. Projetos de sistemas OO (orientados a objetos) devem seguir os princípios para que suas classes tenham alta reusabilidade, baixa dependência e pouco impacto a mudanças. Low Coupling propõe a atribuição de responsabilidade de maneira que o acoplamento permaneça fraco. 2. Problema Como suportar baixa dependência, pouco impacto devido a mudanças e reuso constante? A solução proposta para este problema pelo padrão Low Coupling é atribuir uma responsabilidade para que o acoplamento se mantenha fraco. a) Formas de acoplamento As formas de acoplamento são descritas a seguir: O objeto tem um atributo que referencia outro de outra classe; O objeto possui um método que referencia outro de outra classe; A classe é subclasse de outra direta ou indiretamente. b) Tipos de acoplamento Os tipos de acoplamento entre classes de um sistema OO são os seguintes: b.1) Acoplamento de dados Nesse caso, a saída de um objeto A é entrada para outro B. Exemplo O objeto A passa objeto X para B. Portanto, X e B �cam acoplados. class Servidor { public void mensagem(MeuTipo ObjetoX) { // código aqui ObjetoX.façaAlgo(Object dados); // dados e ObjetoX estão acoplados (se interface de dados // mudar, ObjetoX terá de mudar) // mais código } class Lampada { public �nal static int ON = 0; public void setLampada(int valor) { if(valor == ON) { // liga lampada } else if(valor == 1) { // desliga lampada } else if(valor == 2) { // pisca } } } Lampada lampada = new Lampada(); lampada.setLampada(Lampada.ON); lampada.setLampada(2); Resposta: Decompor a operação em múltiplas operações primitivas. class Lampada { public void on() { // liga lampada } public void off() { // desliga lampada } public void pisca() { // pisca } } Lampada lampada = new Lampada(); lampada.on(); lampada.pisca(); b.2) Acoplamento de dados globais Ocorre quando dois ou mais objetos compartilham uma estrutura de dados pública. Atenção Este é um tipo de acoplamento que esconde o compartilhamento. Por isso, ele deve ser evitado. b.3) Acoplamento de dados internos Ocorre quando um objeto altera dados locais de outro. Atenção Dados públicos, visibilidade de pacotes e uso do tipo de atributo protected em Java. 3. Dicas Uma classe com acoplamento forte (ou alto) depende de muitas outras. Tal classe pode ser indesejável. Classes com acoplamento forte têm os seguintes problemas: As mudanças em classes relacionadas forçam mudanças locais; Estas classes são difíceis de serem compreendidas isoladamente; Estas classes são de difícil reutilização por causa da exigência da presença de outras das quais ela depende. Eis benefícios do padrão Low Coupling: Não é afetado por mudanças em outros componentes; É simples de ser entendido isoladamente; É conveniente para reutilização. Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online Atividade 3 - Em um sistema de biblioteca, qual classe deve ter a responsabilidade de realizar a devolução da cópia do livro e executar o método devolver copia()? Alternativas: A classe Leitor; A classe Livro; A classe Empréstimo. Classes do modelo OO do sistema com seus respectivos atributos: Reserva: Período e situação da reserva; Atendente: Nome do atendente; Leitor: Nome do leitor; Empréstimo: Data e situação do empréstimo; Livro: Possui atributos de título, autor, nome do livro, ISBN, editora e ano; Bibliotecária: Nome da bibliotecária; Cópia do Livro: Situação do livro e status de liberação para empréstimo; Devolução: Data da devolução do livro e a data prevista da devolução. 4 - Quais são as duas responsabilidades dos objetos de um sistema orientado a objetos? a) Conhecer e fazer alguma coisa. b) Saber criar outros objetos e conhecer outras classes relacionadas. c) Conhecer o estado dos outros objetos e dados privados. d) Criar métodos e criar atributos. e) Possuir as mesmas responsabilidades das classes 5 - Atribuir uma responsabilidade para a classe com a informação necessária para satisfazê-la é um objetivo de qual padrão GRASP? a) Controller (controlador) b) Low Coupling (acoplamento fraco) c) Information Expert(especialista na informação) d) High Cohesion (coesão alta) e) Protected Variations (variações protegidas) 6 - No padrão Creator, todas as opções a seguir – exceto uma – são condições válidas para uma classe ter a responsabilidade de criar instâncias (objetos) em outra a �m de cumprir responsabilidades relacionadas a uma classe ou um grupo de classes. Diga qual das opções não apresenta essa condição. a) A classe criadora registra instâncias da outra classe. b) A classe criadora possui dados que serão usados na iniciação e repassados ao construtor da outra classe. c) A classe criadora registra instâncias da outros objetos. d) A classe criadora usa muitos objetos da outra classe. e) A classe criadora contém ou agrega objetos da outra classe. 7 - Medida de quão fortemente uma classe está conectada a outras classes, tem conhecimento delas ou depende delas. Estamos nos referindo a: a) Acoplamento b) Herança c) Polimorfismo d) Responsabilidade e) Dependência Notas Título modal 1 Lorem Ipsum é simplesmente uma simulação de texto da indústria tipográ�ca e de impressos. Lorem Ipsum é simplesmente uma simulação de texto da indústria tipográ�ca e de impressos. Lorem Ipsum é simplesmente uma simulação de texto da indústria tipográ�ca e de impressos. Título modal 1 Lorem Ipsum é simplesmente uma simulação de texto da indústria tipográ�ca e de impressos. Lorem Ipsum é simplesmente uma simulação de texto da indústria tipográ�ca e de impressos. Lorem Ipsum é simplesmente uma simulação de texto da indústria tipográ�ca e de impressos. Referências FRIEMAN, E. Use a cabeça! Padrões de projeto. 2. ed. Rio de Janeiro: Elsevier, 2007. LARMAN, C. Applying UML and patterns: an introduction to object-oriented analysis and design and iterative development. 3. ed. New Jersey: Prentice-Hall, 2004. LEÃO, L. Padrões de projeto de software. Rio de Janeiro: SESES, 2018. Próxima aula Próxima aula Apresentação dos padrões High Cohesion, Controller e Polymorphism. Explore mais Entendendo os conceitos dos padrões de projetos em Java. javascript:void(0);
Compartilhar