RDD - Responsabilidade Driven Design

Para ilustrar algumas das principais idéias em programação orientada a objetos, considerar como nós podemos ir sobre como lidar com a situação do mundo real. Suponha que eu desejo enviar flores para minha avó (Elsa) para seu aniversário. Ela mora longe (Orocovis), de modo a fazê-lo sozinho está fora de questão. No entanto, o envio de suas flores é fácil, eu vou para o meu florista local (Flora), diga-lheos tipos de flores, o número e o endereço, e eu posso ser assegurado que serão entregues. Mecanismo usado para resolver o problema:1. Encontre um agente apropriado (Flora)2. Passar para ela uma mensagem contendo o meu pedido3. É da responsabilidade de Flora para satisfazer o meu pedido. 4. Existe algum método, um algoritmo ou conjunto de operações utilizado por Flora para fazer isso. 5. Eu não preciso saber (ou quer saber) o método especial que ela vai usar. Essa informação está normalmente escondida da minha inspeção. Flora, provavelmente, envia uma mensagem para o outro ligeiramente diferente em florista Orocovis. Isso florista, por sua vez, faz com que o arranjo e passa, juntamente com outra mensagem, para uma pessoa de entrega, e assim por diante.

Primeiro Princípio de OOP :

Resolução de problemas é o veículo pelos quais atividades são iniciadas:Ação é iniciada em OOP enviando uma mensagem para o anunciante e (Objeto) é responsável por essa ação. A codifica a mensagem solicitar uma ação e é acompanhada por quaisquer informações adicionais (Argumentos) necessários para realizar o pedido. Se o receptor aceitar a mensagem, ele aceita a responsabilidade de realizar a ação indicada. Em resposta a uma mensagem, o receptor irá executar algum método para satisfazer o pedido. Temos notado o importante princípio da ocultação de informações em relação à passagem de mensagens, ou seja, o cliente que envia o pedido não precisa conhecer os reais meios pelos quais a solicitação será atendida. Ocultação de informações também está presente em outras línguas convencionais. Em que sentido, é uma mensagem de forma diferente, uma chamada de procedimento? • Existe um receptor designado (agente para o qual a mensagem é enviada). • A interpretação da mensagem (método utilizado para responder à msg) depende do receptor. Normalmente, o receptor específico para um determinado msg não será conhecido até limitadotempo (portanto, o método para invocar não pode ser determinado até então). Assim, dizer que há uma ligação tardia entre a msg e o código usado para responder a msg.

Responsabilidades

Um conceito fundamental em OOP é descrever o comportamento em termos de Responsabilidades. Ao discutir um problema em termos de responsabilidades que aumentar o nível de abstração. Quando você faz um objeto responsável por ações específicas, você esperadeterminado comportamento. Mas tão importante, a responsabilidade implica um grau de independência ou noniterference. A coleção inteira de responsabilidades associada a um objeto é muitas vezes descrita pelo termo protocolo.

Classes e Instâncias Apesar de eu ter tratado apenas com Flora algumas vezes, eu tenho uma idéia do comportamento que pode esperar quando eu entro em sua loja e faço meu pedido. Eu tenho algumas informações sobre o florista em geral, e Flora, sendo um exemplo desta categoria (ou classe), vai caber o padrão geral.

Segundo princípio de OOP: Todos os objetos são instâncias de uma classe. O método invocado por um objecto em resposta a uma mensagem é determinado pela classe do receptor. Todos os objetos de uma determinada classe usar o mesmo método em resposta a mensagens semelhantes.

Hierarquias de classes

Não há mais informações sobre Flora, não necessariamente porque ela é uma florista, mas porque ela é uma lojista. O conhecimento da Flora está organizado em termos de uma hierarquia de categorias. Flora é uma florista, mas Florista é uma forma especializada de Lojista. A Lojista é um ser humano. A Florista classe vontade herdar os atributos da classe lojista.

CRC CARDS

• Muitas vezes é útil, quando você está projetando uma aplicação orientada a objeto, parapensar sobre o processo como sendo semelhante a organizar um grupo de indivíduos, como um clube ou associação. Se todas as ações particulares estão para acontecer, alguém tem de ser responsável por fazê-lo. Nenhuma ação ocorre sem um agente que executa a ação. Um dos objetivos do projeto orientado a objetos é estabelecer quais os responsáveis por cada ação que está para ser executada. • Uma técnica que é muito útil é o uso de cartões de índice para representar aulas individuais. Tais cartões são conhecidos como cartão CRC, uma vez que é dividido em três componentes: classe, responsabilidade e colaboração.

• O objetivo da metodologia é fornecer um quadro em que um conjunto inicial de classes, suas variáveis e métodos pode ser especificado para um novo aplicação. A utilidade do método é o que dá assistência para organizar os seus pensamentos sobre como estruturar um aplicativo. • Este tipo de decomposição é um primeiro passo na compreensão de como um problema pode ser separado em duas partes.

1. CLASSE

• O canto superior esquerdo de cada cartão CRC contém o nome da classe sendo descrito. A seleção dos nomes significativos é extremamente importante, como o nome da classe criar o vocabulário com o qual o projeto será formulado. • Os nomes devem ser internamente consistente, significativa, de preferência curto, e evocativo, no contexto do problema em causa.

2. RESPONSABILIDADES

• Imediatamente abaixo do nome da classe no cartão CRC, as responsabilidades dessa classe estão listadas. Responsabilidades descrever o problema a ser resolvido. Eles devem ser expressas por expressões verbais curtas, cada uma contendo um verbo ativo. • As responsabilidades devem descrever o que deve ser feito, e deve evitar especificações detalhadas de como cada tarefa deve ser cumprida.

3. COLABORADORES

• Alguns objetos podem realizar operações úteis inteiramente por conta própria. Quase todos de pé em alguma relação com vários outros, seja como fornecedores ou como solicitantes de serviço ou facilidade. • A lista de colaboradores deve incluir todas as classes das quais a classe que está sendo descritas para estar ciente. Ele certamente deve incluir classes que fornecem os serviços necessários para atender a responsabilidades da classe que está sendo descrito. Poderia também, mas não necessariamente, incluir classes que requerem serviços prestados pela classe descrita. • A decisão de listar outra classe como um colaborador é baseado no grau de conexão ou cooperação. Ex: Um tipo especial de janela pode estar ligada de forma simétrica aos dados a serem exibidos, e, portanto, seria considerado um colaborador.

Descobrindo Classes

Uma das primeiras decisões que devem ser feitas na criação de uma aplicação é a seleção das classes. As seguintes categorias abrangem a maioria dos tipos de classes: • Gestores de Dados, ou estado: Estas são as classes cujo princípio responsabilidade é a de manter os dados ou informações de estado. Ex: Em um aplicativo de jogo do cartão de cartão de classe irá realizar a classificação ea naipe da carta. • Pias de dados, fontes de dados: as classes que geram os dados (número aleatório gerador), ou aceitar os dados e, em seguida, processá-los ainda mais (classe para executar saída em disco ou arquivo). Ao contrário dos gestores de dados que não possuem os dados para qualquer período de tempo, mas que gera a pedido (por uma fonte de dados), ou processa quando chamado (para um coletor de dados). • Ver ou Observer: Uma parte essencial da maioria das aplicações é a exibição de informações sobre um dispositivo de saída. Como o código para essas atividades é muitas vezes complexo, muitas vezes modificado, e em grande parte independente dos dados reais sendo exibida, é uma boa prática de programação para isolar o comportamento de exibição em classes separadas formam as classes que mantêm os dados que estão sendo exibidos.

Outro conjunto de Classe Categorias • coisas tangíveis: classes mais fáceis de descobrir porque eles são visíveis em domínio do problema. • Interfaces de sistema e dispositivos: fácil de descobrir, considerando a recursos do sistema e as interações do sistema. Ex: DisplayWindow. • agentes: Às vezes é útil para alterar uma operação em um agente

classe. Por exemplo, uma classe InputReader podem ser criados para separar o operação de obtenção de texto, que é usado para construir uma mensagem pela Classe de mensagem. A classe de agente separa a classe Mensagem do input mecanismos e separa os níveis de abstração de processamento de entrada e controle de conteúdo da mensagem. • Eventos e Transações: úteis para registros no modelo de atividades que descrever o que aconteceu no passado, ou o que precisa ser feito mais tarde. Para exemplo, uma classe CustomerArrival para especificar onde, quando o tipo de cliente está programado para chegar. Ex: MouseEvent • Usuários e funções: stand-ins para os usuários atuais do programa. Para Exemplo de classe Administrador é uma interface para o ser humano administrador do sistema.

• Sistemas: modelo de um subsistema ou de todo o sistema que está sendo construído. Seu papel são tipicamente para executar a inicialização e desligamento e para iniciar o o fluxo de entrada para o sistema. • Containers: usado para armazenar e recuperar informações. Muitos são implementada usando as estruturas de dados padrão (listas, filas, ...).

Concepção dos cenários Projetando com cartões CRC segue nem o "top-down", nem o "bottom- up "modelos de desenvolvimento de software. Em vez disso, o desenho pode ser dito progredir a partir do conhecido para o desconhecido. O processo de concepção deve começar com apenas as classes mais evidentes, e a classes necessárias para lidar com o início de um pedido. O designer (s), em seguida, continuar jogando "what if" - através da simulação de cenários que ilustram o uso esperado. Os cartões CRC pode desempenhar um papel concreto neste processo de simulação. Como cada ação no cenário é identificada, é atribuído como uma responsabilidade a um objeto específico. Diferentes cenários são, então, tentei, e muito mais responsabilidades são gerados. Designers devem ser encorajados a trabalhar com o problema imediato em lado, e não para tentar antecipar possíveis necessidades futuras que têm ainda não foi encontrado. Muitas vezes, as responsabilidades moverá forma um objeto para outro, como o projeto evolui sob pressão de diferentes cenários. A vantagem do índice cartão é que eles são baratos, facilmente substituível, e mutável. A técnica de cenário incentiva uma abordagem experimental para projetar. Uma vez que os cartões são facilmente modificados de modo, o design diferente podem ser avaliadas rapidamente. O desenvolvimento de um sistema de software real com base no CRC cartões é um processo de refinamento iterativo.

Automated Teller Machine Exemplo Quando a sua marcha lenta, uma mensagem de saudação é exibida. As chaves e depósito Slot permanecerá inativo. Quando um cartão é inserido, o leitor de cartões tenta lê-lo. Se o cartão não pode ser lido, o utilizador é informado, e sua ejectado. Se o cartão é lido, o usuário é solicitado a digitar um PIN. Se a sua entrada

corretamente, o usuário é apresentado o menu de atividades. Caso contrário, o usuário é dadas duas chances adicionais para introduzir o PIN. Se não o fizer no terceira tentativa faz com que o aparelho para manter o cartão. O menu de atividades contém uma lista de transações que podem ser realizada. Estes incluem: depósito, retirada, consulta do saldo, transferência de fundos, e encerrar a atividade. Cenário Quando o usuário se aproxima do caixa eletrônico, há uma mensagem de boas-vindas e algo para receber o cartão do utilizador. Enquanto o cartão está, o sistema deve ler as informações da conta, pedir o PIN, e determinar se a sua correta O PV usa a informação de conta para determinar o PIN e, em seguida, pedir ao usuário para digite o número a ser verificado. Se o PIN estiver correto, então o usuário é dada a escolha de seleções. O usuário seleciona um item e controle passa para os gestores da selecção apropriada Um sistema separado controla a gaveta para aceitar depósito ou dispensar dinheiro.

Gerentes de dados O próximo passo no processo de refinação da especificação enfatiza a gestão de valores de dados. Esta etapa deve ser tomada apenas após um conjunto aceitável de responsabilidades foi estabelecida. É importante distinguir entre dados de durabilidade, isto é, aqueles valores que deve ser mantida durante um período de tempo significativo ou usado por um grande número de indivíduos e valores de dados de curta duração.

A princípio a seguir pode ser descrita como base de dados responsáveis gestão: Qualquer valor que vai ser acedida ou modificado amplamente, ou que venham a existir para um período significativo de tempo, deve ser gerida. Ou seja, uma e somente uma classe deve ter a responsabilidade pelas ações levado para visualizar ou alterar os valores. Todas as outras classes que precisam para obter os valores devem passar pedidos para o gerente para tais ações, ao invés de acessar os dados em si. Descobrindo Inheritance

Uma vez que o projeto inicial é acordado, o reconhecimento de comunalidade pode facilitar ainda mais o desenvolvimento. (Podemos afirmar que esta dizendo que herança é uma técnica de aplicação útil, mas não é um projeto técnica). Duas relações são de importância fundamental. O IS-A e tem-um relacionamento. • A relação é-um possui entre dois conceitos quando o primeiro é um instância especializada da segunda (herança). • A-tem uma relação segura quando o segundo conceito é um componente do primeiro, mas quando os dois não são, em nenhum sentido a mesma coisa, não importa o quão abstrato da generalidade (contenção).

Comuns falhas de projeto • Classes que fazem modificação direta com outras classes

• Classes com muita responsabilidade • Classes sem responsabilidade • Classes com responsabilidade sem uso • nomes enganosos • responsabilidades desconectados • O uso inadequado de herança • funcionalidade repetida

cartões CRC

Uma técnica simples, mas poderosa para apoiar o projeto orientado a responsabilidade é cartões CRC (Classe, Responsabilidade, Colaboração) inventado por Kent Beck e Ward Cunningham (Beck & Cunningham, 1989).

Você pode usar cartões de índice (15x10 cm). Cada carta representa uma classe (candidato). Seu nome está escrito no topo, as suas responsabilidades são mencionados à esquerda, e as classes que colabora com são listados à direita. A imagem abaixo mostra um exemplo do cartão CRC para um processo de workflow. Ele sabe como orientar o trabalho por meio de uma ou mais tarefas. Ele colabora com tarefas e itens de trabalho para o conseguir.

Em uma sessão de design, você usa os cartões para tentar rapidamente diferentes cenários e obter feedback sobre como você atribuiu responsabilidades a classes.

Embora esta técnica é de 20 anos de idade, ainda é muito útil, com a vantagem adicional de que você não precisa comprar uma ferramenta de modelagem caro.

Cartões CRC não são necessariamente classes concretas. São principalmente os papéis que os objetos vão jogar. Cada papel vem com as suas responsabilidades. A idéia de papéis de modelagem e objetos é amplamente coberto em (Reenskaug, 1995).

No código, os papéis serão implementados pelas interfaces e os objetos por classes. Esta abordagem resulta em componentes de baixo acoplamento e um monte de definições de interface.

Driven design responsabilidade refere-se também projetar diretrizes, como o princípio da responsabilidade única - cada unidade deve ter apenas uma responsabilidade (Martin, 2002).

Test Driven Development

Test Driven Development (TDD) é uma prática de desenvolvimento que suporta driven design responsabilidade. TDD direciona o projeto de escrever testes de unidade. Ao fazer TDD, você mantém o código e seu design em boa forma por refactoring continuamente (Beck, 2003). Refactoring significa melhorar o projeto de código existente, sem alterar seu comportamento em geral.

Os passos de TDD são enganosamente simples:

1. em primeiro lugar, escrever um teste de unidade 2. certifique-se o teste falhar - testar o teste 3. adicionar código passo a passo, apenas o suficiente para fazer o teste passar 4. refatorar o código - remover a duplicação e garantir que o código revela suas intenções 5. repetir

TDD leva você para unidades independentes em seu design, como dependências entrar em seu caminho ao escrever testes de unidade. Por isso, impõe um baixo acoplamento, design coesa.

Muitos que começam com TDD luta com a obtenção de um controle sobre as dependências. Para testar um objeto, você se exercita um comportamento e, em seguida, verificar se um objeto está em um estado esperado. Porque o design OO foca no comportamento, o estado de um objeto é geralmente escondido (encapsulados). Para ser capaz de verificar se um objeto se comporta como esperado, às vezes você precisa acessar o estado interno e introduzir métodos especiais para expor este estado, como um método getter ou uma propriedade que recupera o estado interno.

Além de não querer objetos bagunçando suas interfaces e expondo suas partes íntimas, nós não queremos introduzir dependências desnecessárias com tais getters extras. Nossos testes vai se tornar muito intimamente ligado e focado em detalhes de implementação.

Referências

Confira o próximo livro Growing Object-Oriented Software, guiado por testes pelos inventores de objetos simulada Steven Freeman e Nat Pryce - http://www.mockobjects.com/book

Rebecca Wirfs-Brock & Alan McKean, objeto de design: papéis, responsabilidades e colaborações, Addison-Wesley 2003

Kent Beck, Ward Cunningham, um laboratório para o ensino do pensamento orientado a objeto, 1989 - http://c2.com/doc/oopsla89/paper.html

Kent Beck, Test Driven Development: By Example, Addison-Wesley 2002

Martin Fowler, Mocks não são Stubs, 2004 - http://martinfowler.com/articles/mocksArentStubs.html

Tim Mackinnon, Steve Freeman, Philip Craig, Endo-teste: Teste de unidade com objetos Mock, 2000 - http://www.mockobjects.com/files/endotesting.pdf

Steve Freeman, Nat Pryce, Tim Mackinnon, Joe Walnes, Roles Mock, nem objetos, 2004 - http://www.mockobjects.com/files/mockrolesnotobjects.pdf

Robert C. Martin, Desenvolvimento Ágil de Software, Princípios, Padrões e Práticas, Prentice Hall 2002

Trygve Reenskaug, trabalhando com objetos: O Método Engenharia de Software Ooram, Prentice Hall 1995

GRASP – como atribuir responsabilidades com eficiência, uma introdução

A programação orientada a objetos é, de longe, o paradigma mais utilizado em programação. Com várias décadas de existência, (apesar de muita gente não saber, a OO surgiu com as linguagens SIMULA I (1962-65) e Simula 67 (1967)) evoluiu bastante, porém, é muito comum encontrar projetos com problemas de arquitetura dos mais diversos tipos, entre eles, problemas de coesão, acoplamento desnecessários, generalizações inconsistentes e outras.

O intenção deste artigo é introduzir o conceito de GRASP (General Responsibility Assignment Software Patterns), que, conforme o nome já diz, tem o objetivo de tornar a distribuição de responsabilidade entre as classes uma tarefa mais criteriosa e eficiente, melhorando de forma significativa a qualidade de seu projeto e reduzindo os problemas de arquitetura mais comuns.

A maioria dos programadores aprendeu que em POO devemos mapear objetos reais para objetos em seu modelo de classes. Isto muitas vezes é seguido a risca, mas nem sempre é a melhor maneira de modelar suas classes, pois muitos detalhes cruciais só são visíveis ao se considerar o contexto geral, ou seja, a forma como esses objetos vão interagir e como eles vão colaborar uns com os outros. Os padrões GRASP surgiram exatamente para auxiliar nesta questão.

O GRASP descreve ao todo nove padrões ou princípios, a saber:

1. Especialista de informação (Expert) 2. Criador (Creator) 3. Alta coesão (High coesion) 4. Baixo acoplamento (Low coupling) 5. Controlador (Controller) 6. Polimorfismo (Polymorphism) 7. Invenção pura (Pure Fabrication)

8. Indireção (Indirection) 9. Variação protegida (Protected Variations)

Cada um destes padrões trata de um problema específico, e sugere uma solução de arquitetura para superá-lo. A solução pode utilizar alguns dos consagrados padrões GoF (que poderá ser assunto aqui no AgileZ), portanto é recomendável que o programador ou analista conheça bem soluções como Observer pattern, Proxy, Iterator, Adapter, Strategy, Singleton entre outros.

Antes de começar a descrever cada um dos nove padrões, convém conceituar o que é responsabilidade. Uma responsabilidade pode ser descrita como uma obrigação, seja obrigação de fazer ou conhecer alguma coisa.

Fazer algo:

a si mesmo começar ações em outros objetos controlar ações em outros objetos

Conhecer algo:

informações encapsuladas objetos relacionados informações que pode calcular

Exemplo: uma classe Memo pode ter obrigação de gerar linhas (faz algo a si mesma), ou pode utilizar uma classe Linha para isso (inicia uma ação em outro objeto) e controlar essas ações mantendo um contador de linhas (informações encapsuladas). Para isso, o Memo deve conhecer a classe Linha (objetos relacionados).

Não devemos, entretanto, confundir métodos/operações com responsabilidades. Um ou vários métodos devem ser utilizados para implementar uma determinada responsabilidade.

I. O padrão Expert (Especialista de informação)

O primeiro padrão que deve ser considerado para resolver o problema de atribuição de responsabilidade é o Expert, que diz que o primeiro candidato a receber a responsabilidade é aquele que possui a informação necessária para executar a tarefa.

O exemplo mais comum é o da venda. Nosso sistema precisa calcular o total de uma venda. Qual classe deve ser responsável por fazer este cálculo?

Sabemos que, para calcular o total de uma venda, precisamos somar os totais de cada item, além do desconto e juros, se houver. Olhando o diagrama, fica fácil observar que a classe Venda é a classe que mantém a lista de itens (dona da informação), portanto ela é a primeira candidata a calcular o total.

Utilizando o padrão Expert, atribuímos à classe Venda a responsabilidade por calcular o total da venda. Como será feito o cálculo internamente? A classe Venda deve iterar pelos itens, somando os valores de cada um e depois subtrair os descontos e somar os acréscimos. Mas, e o valor do item, quem deve calcula-lo? Aplicando novamente o padrão Expert, podemos observar que é o Item quem possui a informação necessária para essa tarefa (quantidade), e o produto é quem possui o preço, logo, as responsabilidades, seguindo o padrão Expert, ficariam assim:

É lógico que este foi um exemplo bem simples, e provavelmente nenhum analista precisaria conhecer o GRASP para chegar ao modelo proposto, mas, ao tratar de relacionamentos e projetos mais complexos, fica bem mais difícil manter um modelo consistente, altamente escalável e flexível, sem conhecer bem esses padrões.

GRASP Patterns David Duncan 16 de novembro de 2012

Introdução • GRASP (General Responsabilidade Assignment Software Padrões) é um acrônimo criado por Craig Larman para englobam nove princípios de design orientado a objeto relacionada com a criação de responsabilidades para as classes • Estes princípios podem ser vistos como cartão padrões e oferecem benefícios semelhantes ao clássico "Bando dos Quatro" padrões • GRASP é uma tentativa de documentar o especialista projetistas provavelmente sabe intuitivamente • Todos os nove padrões GRASP serão apresentadas e brevemente discutido

Qual é o alcance? • GRASP = Geral Responsabilidade Assignment Software Padrões (ou princípios) Projeto • Uma coleção de geral opôs-oriented padrões relacionados com a atribuição de definir os objectos • descrita originalmente como uma coleção de Craig Larman em Aplicando UML e Padrões: Uma Introdução à Análise Orientada a Objetos e Design, uma ª edição, em 1997.

Contexto (1 de 2) • A terceira edição do Aplicando UML e Patterns é o edição mais recente, publicado em 2005, e é de longe a fonte mais mobilizados para este material • Larman assume o desenvolvimento de algum tipo de artefatos de análise prévia ao uso de GRASP - Da nota particular, um modelo de domínio é usado • Um modelo de domínio descreve o domínio do assunto sem descrever a implementação de software • Pode parecer semelhante a um diagrama de classes UML, mas há uma grande diferença entre objetos de domínio e objetos de software

Context (2 de 2) • Caso contrário, os pressupostos são amplas: em primeiro lugar, o praticante está usando algum tipo de sensata e processo iterativo - Larman escolhe o Unified Process, pois é: • Iterativo • flexível e aberta, se integra bem com processos ágeis • Popular com projetos OOAD

Projeto Responsabilidade-Driven • padrões GRASP são usados para atribuir a responsabilidade a objetos • Como tal, o seu uso resulta em uma responsabilidade-Driven Projeto (RDD) para Orientação a Objetos (OO) - Contraste a (o mais tradicional) projeto orientado a dados • Com este ponto de vista, a atribuição de responsabilidades aos objetos é uma grande parte do projeto básico objeto

Por entender? • Tradicionalmente, em Programação Orientada a Objetos (OOP), objeto projeto é encoberto - Por exemplo, pense em substantivos e converter a objetos, pense de verbos e convertê a métodos - Ou ainda: Após análise de requisitos e criação de um modelo de domínio, apenas criar objetos e seus métodos para cumprir exigências • (Oh. ... Ok. Pobres desenvolvedores OO inexperientes.) • UML é apenas uma linguagem que expressa um projeto OO, mas para a maior parte não fornece orientação • Por Larman, GRASP ajuda a "entender o objeto essencial projetar e aplicar o raciocínio em uma metódica, racional, maneira explicável. "

Design Patterns • padrões de projeto de software foram lançados como um conceito em 1987 por Kent Beck e Ward Cunningham, baseado em Christopher Alexander aplicação em (edifício), arquitetura

• Núcleo definição: a descrição de um problema chamado e uma solução correspondente reutilizável • O ideal é que o padrão aconselha sobre quando deveria ser utilizado eo típico trade-offs • Os padrões de design mais famosos são o 23 descrito pelo "Gang of Four" (GoF) livro em 1993

Vantagens do design padrão • Ambos os padrões GoF e padrões GRASP tem benefícios notáveis: - Simplificar: fornece um nome, geralmente entendida bloco de construção • Facilita a comunicação • Aids pensamento sobre o projeto - Acelera o aprendizado para não ter de desenvolver conceitos de arranhar

GRASP vs Padrões GoF • padrões GRASP são de uma forma ainda mais fundamental do que os padrões GoF - Padrões GRASP são igualmente bem conhecido como princípios enquanto que os padrões GoF raramente são referidos como tal • Enquanto a nomeação de ambos os tipos de padrões é importante, é menos importante para os padrões GRASP - Os conceitos são verdadeiramente o que são importantes

Sobre Responsabilidades • Dois tipos de responsabilidades para os objetos: - Fazer - Conhecendo • Conhecer as responsabilidades são muitas vezes facilmente inspirado por software objetos de domínio classe Venda em OO- Por exemplo, a classe de domínio para a venda tem um atributo de tempo cartão conhece a sua vez também - Resultado da reunião o modelo objetivo de domínio para ter um baixo Gap representacional (LRG) • responsabilidades Fazendo muitas vezes vêm de modelagem cedo - Por exemplo, cada mensagem em um diagrama de interação UML é sugestivo de algo que deve ser feito

GRASP padrões • Há nove padrões GRASP, provavelmente alguns já reconhecível e outras não: - Criador - Especialista da Informação (ou apenas Expert) - Low Coupling - Controller - High Coesão - Polimorfismo

- Fabricação Pure - Indireção - Variações Protegidas • (NOTA: O problema e as demonstrações de soluções que seguem são quase literalmente de Larman, com exceção de alguns poucos menor tentativas de adição de clareza.)

Criador • Problema: Quem deve ser responsável pela criação de um novo instância de alguma classe? - Se mal feito, essa escolha pode afetar o acoplamento, clareza, encapsulamento, e reutilização. • Solução: Atribuir classe B a responsabilidade de criar um instância da classe A se uma das abaixo é verdadeira (mais o melhor). Se mais de uma opção se aplica, geralmente preferem uma classe B, que contém agregados ou A. - B contém ou é constituído por: A. - B registros A. - B de perto usa A. - B tem os dados para inicializar A que vai ser transmitida para A quando é criado. • Assim, B é um especialista no que diz respeito à criação de A.

Discussão Creator • Este padrão geralmente evita a adição de acoplamento para um projeto (o que é ruim para ver padrão GRASP n º 3). • Quando a criação é um processo complexo e varia dependendo de uma entrada, muitas vezes você vai querer criar usando uma classe diferente implementar o padrão GoF Fábrica de cimento ou Abstract Factory.

Informações Especialista • Problema: O que é um princípio geral de atribuição responsabilidades para com os objetos? • Solução: Atribuir a responsabilidade de as informações expert-classe que tem as informações necessárias para cumprir a responsabilidade.

Informações Discussão Especialista • Este é o princípio geral e, provavelmente, o mais utilizado de qualquer padrão GRASP. • Isso geralmente é a chave para acoplamento e alta a coesão, mas nem sempre assim. - Imagine um caso em que é melhor entregar os dados em ordem para preservar uma grande divisão funcional e coesão ajuda. • Nós estamos implicitamente falando sobre informações detidas por um objeto de software, mas se não houver relevante classes de software, experimente o modelo de domínio.

Low Coupling

• Problema: Como apoiar baixa dependência, baixo mudar impacto e aumento da reutilização? • Solução: Atribuir uma responsabilidade para que o acoplamento permanece baixa. Utilize este princípio para avaliar alternativas. - Acoplamento refere-se a qualquer tipo de dependência tangível entre elementos de classes, subsistemas, sistemas, etc - e é referenciado pelo seu grau: • Fraco (baixo) é bom. • Strong (alto) é ruim.

Baixa Discussão Coupling • acoplamento Superior pode levar a: - Mais dificuldade na compreensão - Mudanças propagação excessivamente - Mais obstáculos à reutilização de código • acoplamento inferior muitas vezes anda de mãos dadas com maior coesão (bom ver GRASP padrão # 5). • Considere este princípio com todas as decisões de design. • Note-se que muito pouco acoplamento indica que algo está errado com o design, provavelmente incluindo baixa coesão - No RDD (e realmente OO), o objetivo é ter uma ampla rede de objetos focados usar a comunicação para cumprir os requisitos de forma organizada moda. • Quanto mais instável a classe acoplado a, mais sobre a conexão - Por exemplo, considere a biblioteca padrão de uma língua contra uma classe um colega de trabalho acabou de definir há alguns dias atrás.

Controlador • Problema: O primeiro objeto para além da camada UI Recebe e coordenadas ("controles"), um sistema de operação? • Solução: Atribuir a responsabilidade de um dos seguintes tipos de classes: - Fachada Controlador: representa o "sistema" em geral, a "raiz objeto ", ou de um dispositivo que o software está sendo executado - Caso de uso ou controlador de sessão: representa um caso de uso cenário em que ocorre um evento do sistema (por exemplo, "adicionar um entrada da agenda ") • A classe normalmente seria chamado Handler <UseCaseName>, Coordenador <UseCaseName>, ou Session <UseCaseName>

Controlador de Discussão • Um controlador tenta coordenar o trabalho sem fazer muito do que a si mesmo (mais uma vez, guiados por os graus de acoplamento e coesão) - A palavra-chave é delegação. • Um exemplo simples disso é que os objetos de interface do usuário não deve

executar a lógica de negócios, há outras classes de que. • O controlador do Model-View-Controller (MVC) arquitetura é efetivamente a mesma coisa. - Isso, ou sua variação Model-View-Presenter, é freqüentemente usado em aplicações web

Alta Coesão • Problema: Como manter objetos focado, compreensível, e manejável, e como um lado efeito, o apoio Low Coupling? • Solução: Atribuir uma responsabilidade para que a coesão continua a ser elevada. Use-o para avaliar alternativas. - Coesão refere-se à coesão entre funcional elementos (classes, sistemas, subsistemas, etc), que é uma medida de quão fortemente centrada as responsabilidades de um elemento são.

Discussão alta de Coesão • Muito semelhante ao Low Coupling - Muitas vezes, relacionada (mas não sempre) - Deve ser considerado em todas as decisões de design. • Baixa coesão quase sempre significa: - Um elemento mais difícil de entender, manter ou reutilizar - Um elemento mais propensos a ser afetados pela mudança • Baixa coesão sugere que mais delegação deve ser usados.

Polimorfismo • Problema: Como lidar com alternativas com base no tipo? Como criar pluggable componentes de software? • Solução: Quando alternativas ou comportamentos relacionados variam consoante o tipo (classe), atribuir responsabilidades para o comportamento usando polimórfica operações para o tipos para os quais o comportamento varia. - Operações polimórficas são aquelas que operam em diferentes classes de - Não teste para o tipo de objeto e use condicional lógica para executar diferentes declarações com base no tipo.

Polimorfismo • No que diz respeito à implementação, isso significa normalmente a utilização de um super (pai) de classe ou de interface - Codificação de uma interface é geralmente preferido e evita comprometendo-se a uma hierarquia de classes particular. • código como o seguinte deve levantar uma bandeira vermelha! Mudar creatureType Caso batType: print "Screech!" Caso cowType: print "Moooooo ..."

Caso humanType: print "Vamos assistir TV!" [...] • Ver também Padrão GRASP n º 8, Variações Protegidas.

Fabricação Pure • Problema: O objeto deve ter a responsabilidade, quando você não quer violar alta coesão e Baixo acoplamento, ou outros objetivos, mas as soluções oferecidas por especialistas (por exemplo) não são apropriadas? • Solução: Atribuir um conjunto muito coeso de responsabilidades para com uma classe artificial ou conveniência que não representa um domínio de problema conceito, algo inventado, para suportar alta coesão, baixo acoplamento e reutilização.

Fabricação Pure Discussão • Em outras palavras, recebendo conceitos de classe a partir de um bom domínio modelo ou da vida real objetos nem sempre funcionam bem! • Um exemplo de uma possível classe pura fabricação: PersistentStorage - Pode muito bem não ser o modelo de domínio - Pode muito bem não mapear para um objeto da vida real - Mas pode ser a resposta para alcançar nossos objetivos de baixo acoplamento / alta coesão enquanto continua a ter uma responsabilidade clara • Observe que todos os padrões de projeto GoF são puras fabricações (muitas vezes de múltiplas classes)

Vias indiretas • Problema: Onde atribuir uma responsabilidade, para evitar acoplamento direto entre duas coisas (ou mais)? Como para separar os objetos de modo que o baixo acoplamento é apoiou e continua a ser maior potencial de reutilização? • Solução: Atribuir a responsabilidade de um intermediário opor-se a mediar entre outros componentes ou serviços, de modo que eles não estão directamente acoplados. - O intermediário cria o engano.

Indireção Discussão • Muitas vezes, um intermediário indireto também é um puro fabricação. - O exemplo PersistentStorage poderia muito bem ser um indireto entre uma classe Venda e banco de dados. • O GoF padrões Adapter, Bridge, Fachada, Observer, e Mediador todos fazer isso. • O principal benefício é o acoplamento mais baixa.

Variações Protegidas • Problema: Como projetar elementos (objetos, subsistemas e sistemas) de modo que as variações ou instabilidade dos elementos não tem um

indesejável impacto sobre outros elementos? • Solução: Identificar pontos de variação previsto ou instabilidade, atribuir responsabilidades para criar uma estável Interface em torno deles.

Variações protegido Discussão • Na solução de "interface" é significado no sentido geral, mas muitas vezes você vai pretende utilizar uma construção de programação de interface (em Java, por exemplo) para implementar a solução! • Benefícios: - Fácil de estender a funcionalidade em pontos PV - Acoplamento Lower - Implementações podem ser atualizados sem afetar clientes - Reduz o impacto da mudança • Muito semelhante ao princípio aberto fechado ou o conceito de informação esconder (não o mesmo que esconder dados) • Na primeira edição do Larman, foi a Lei de Demeter, mas Protegido Variações é uma expressão mais generalizada • "desenvolvedores novatos tendem a projetos frágeis, desenvolvedores intermediários tendem a excessivamente sofisticados e flexíveis, as generalizadas (de maneiras que nunca se acostuma). Os designers especialistas escolher com discernimento. "

Para mais informações ... • Para mais informações sobre GRASP, é difícil de bater a profundidade de Larman de texto: - Larman, Craig Aplicando UML e Patterns: An Introduction to Object-. Análise e Projeto Orientado e desenvolvimento iterativo. Terceiro edição, Prentice Hall, 2005. • É bem escrito e também há material considerável em UML, ágil, GoF padrões de projeto, uma perspectiva de nível de projeto e muito mais. • Se GRASP não golpear uma corda, há alternativa abordagens para a questão geral de "Como faço para criar um OO projeto usando objetos "Por exemplo?: . - Wirfs-Brock, Rebecca e McKean, Alan objeto de design: Funções, Responsabilidades e colaborações. Addison-Wesley Professional, 2002. . - Evans, Eric Domain-Driven Design: Combater Complexidade no coração de Software. Addison-Wesley Professional, 2003.

Conclusão • GRASP fornece um mapa de considerações para fornecer forte orientação para um designer de OO • Mas, ao mesmo tempo, GRASP ainda deixa muito espaço para o designer e criar um bom projeto ainda é um arte! • Dando uma olhada no GRASP e realmente Aplicando UML e Patterns-é uma boa aposta para OO designers que conhecer os princípios básicos de OOP, mas ainda é inexperiente