Design baseado em responsabilidade

Da Wikipédia, a enciclopédia livre
Ir para a navegação Saltar para pesquisar

O design orientado por responsabilidade é uma técnica de design em programação orientada a objetos , que melhora o encapsulamento usando o modelo cliente-servidor . Ele se concentra no contrato considerando as ações pelas quais o objeto é responsável e as informações que o objeto compartilha. Foi proposto por Rebecca Wirfs-Brock e Brian Wilkerson.

O design orientado por responsabilidade está em contraste direto com o design orientado a dados, que promove a definição do comportamento de uma classe junto com os dados que ela contém. O design orientado a dados não é o mesmo que a programação orientada a dados , que se preocupa com o uso de dados para determinar o fluxo de controle , não o design de classes.

No modelo cliente-servidor a que se referem, tanto o cliente quanto o servidor são classes ou instâncias de classes. Em qualquer momento específico, o cliente ou o servidor representa um objeto. Ambas as partes se comprometem com um contrato e trocam informações aderindo a ele. O cliente só pode fazer as solicitações especificadas no contrato e o servidor deve responder a essas solicitações. [1] Assim, o design orientado a responsabilidade tenta evitar lidar com detalhes, como a forma como as solicitações são realizadas, especificando apenas a intenção de uma determinada solicitação. O benefício é o aumento do encapsulamento, já que a especificação da maneira exata como uma solicitação é realizada é privada do servidor.

Para promover o encapsulamento do servidor, Wirfs-Brock e Wilkerson pedem recursos de linguagem que limitam a influência externa ao comportamento de uma classe. Eles exigem que a visibilidade de membros e funções seja finamente granulada, como na linguagem de programação Eiffel . Um controle ainda mais preciso da visibilidade de classes pares está disponível na linguagem de programação Newspeak .

Visão geral

O design orientado à responsabilidade foca nos objetos como abstrações comportamentais que são caracterizadas por suas responsabilidades. A técnica de modelagem de cartão CRC é usada para gerar essas abstrações comportamentais. O restante da estrutura do objeto, incluindo os atributos de dados, são atribuídos posteriormente, conforme e quando necessário. [2] Isso faz com que o design siga a hierarquia de tipos para herança, o que melhora o encapsulamento e facilita a identificação de classes abstratas . Ele também pode agrupar as classes com base em seus clientes, o que é considerado uma habilidade única.

Um bom design orientado a objetos envolve um foco inicial em comportamentos para realizar os recursos que atendem aos requisitos declarados e uma vinculação tardia dos detalhes de implementação aos requisitos. Essa abordagem ajuda especialmente a descentralizar o controle e distribuir o comportamento do sistema, o que pode ajudar a gerenciar as complexidades de sistemas grandes ou distribuídos de alta funcionalidade . Da mesma forma, pode ajudar a projetar e manter instalações de explicação para modelos cognitivos , agentes inteligentes e outros sistemas baseados em conhecimento . [3]

Blocos de construção

Em seu livro Object Design: Roles , Responsibilities and Collaborations [4] os autores descrevem os seguintes blocos de construção que compõem o design orientado por responsabilidade.

  • Aplicativo: Um aplicativo de software é referido como um conjunto de objetos que interagem. [5]
  • Candidatos: Candidatos ou objetos candidatos são conceitos-chave na forma de objetos descritos em cartões CRC. Eles servem como invenções iniciais no processo de design de objetos. [6]
  • Colaborações: Uma colaboração é definida como uma interação de objetos ou papéis (ou ambos). [5]
  • Cartões CRC: CRC significa Candidatos, Responsabilidades, Colaboradores. Eles são cartões de índice usados ​​no projeto inicial para registrar candidatos. [7] Estas cartas são divididas em um lado sem forro e um lado forrado.
    • Conteúdo do lado pautado: Neste lado estão registrados o nome do candidato, suas responsabilidades e seus colaboradores. [7]
    • Conteúdo do lado sem linhas: Neste lado são registrados o nome do candidato, sua finalidade na candidatura, papéis estereotipados e qualquer coisa que valha a pena, como os nomes dos papéis nos padrões dos quais ele participa. [7]
  • Hot Spots: Hot Spots são pontos na aplicação onde ocorrem variações. Eles são registrados usando Hot Spot Cards. [8]
  • Cartões Hot Spot: Os Cartões Hot Spot são usados ​​para gravar variações com detalhes suficientes para que você possa discriminar diferenças importantes. Semelhante aos cartões CRC, estes também são criados a partir de cartões de índice . [8] Esses cartões consistem em:
    • Nome do ponto de acesso
    • Descrição geral da variação
    • Pelo menos dois exemplos específicos onde a variação ocorre

Objetos

Os objetos são descritos como coisas que têm comportamentos semelhantes a máquinas que podem ser conectados para funcionar em conjunto. Esses objetos desempenham papéis bem definidos e encapsulam respostas e informações com script. [5]

  • Object Neighborhoods: Outro termo para subsistema. [9] É um agrupamento lógico de colaboradores. [9]
  • Responsabilidades: Uma responsabilidade é uma obrigação de realizar uma tarefa ou conhecer uma informação. [5] Estes são ainda categorizados de acordo com seu cenário de uso.
    • Responsabilidades Públicas: As responsabilidades públicas são as responsabilidades que um objeto oferece como serviços a outros e as informações que fornece a outros. [10]
    • Responsabilidades Privadas: As responsabilidades privadas são as ações que um objeto realiza em apoio às responsabilidades públicas. [10]
    • Subresponsabilidades: Às vezes, uma responsabilidade grande ou complicada é dividida em outras menores chamadas subresponsabilidades. [11] Eles são ainda categorizados com base no que fazem.
      • Responsabilidades Subordinadas: Estas incluem as principais etapas de cada subresponsabilidade. [11]
      • Responsabilidades de Sequenciamento: Referem-se ao sequenciamento da execução das responsabilidades subordinadas. [11]

Funções

O papel do objeto refere-se a uma visão externa de qual serviço geral é oferecido pelo objeto. É um conjunto de responsabilidades relacionadas. [5] Pode ser implementado como uma classe ou uma interface. Interface, no entanto, é a implementação preferida, pois aumenta a flexibilidade ocultando a classe concreta que, em última análise, faz o trabalho. [12]

Estereótipos de função: os estereótipos de função são funções simplificadas que vêm com responsabilidades predefinidas. [13] Existem várias categorias.

  • Controlador: O objeto que implementa essa função toma decisões e direciona de perto a ação de outros objetos. [13]
  • Coordenador: Esta função reage aos eventos delegando tarefas a outras pessoas. [13]
  • Titular da informação: O titular da informação conhece e fornece informações. [13]
    • Provedor de Informação: Uma pequena variação de um detentor de informação é o provedor de informação, que tem um papel mais ativo no gerenciamento e manutenção da informação. Essa distinção pode ser usada se um designer precisar ser mais específico. [14]
  • Interfacer: Essa função transforma informações e solicitações entre partes distintas de um aplicativo. [13] Está ainda dividido em funções mais específicas.
    • Interface Externa: Interface externa comunica-se com outras aplicações em vez de sua própria. [14] É usado principalmente para encapsular APIs não orientadas a objetos e não colabora muito. [15]
    • Interface interna: Também chamada de interface intersistema. [14] Atua como uma ponte entre as vizinhanças dos objetos. [15]
    • Interface do usuário: o interface do usuário se comunica com os usuários respondendo a eventos gerados na interface do usuário e, em seguida, passando-os para objetos mais apropriados. [14] [15] [16]
  • Provedor de Serviços: Esta função realiza o trabalho e oferece serviços de computação. [14]
  • Estruturador: Esta função mantém relacionamentos entre objetos e informações sobre esses relacionamentos. [14]

Estilo de controle

Uma parte importante no processo de design orientado por responsabilidade é a distribuição de responsabilidades de controle que resulta no desenvolvimento de um estilo de controle. Um estilo de controle está preocupado com o fluxo de controle entre os subsistemas .

  • Conceito de Controle: As responsabilidades e colaborações entre as classes. [17]
  • Centros de Controle: Um aspecto importante do desenvolvimento de um estilo de controle é a invenção dos chamados centros de controle. São lugares onde residem os objetos encarregados de controlar e coordenar. [18]
  • Variações de estilo de controle: Um estilo de controle vem em três variações distintas. Essas não são definições precisas, uma vez que um estilo de controle pode ser considerado mais centralizado ou delegado do que outro.

Estilo de controle centralizado

Esse estilo de controle impõe um paradigma de procedimento na estrutura do aplicativo e coloca as responsabilidades de tomada de decisão em apenas alguns objetos ou em um único objeto.

Tipos
  • Modelo de retorno de chamada: O controle dos objetos na aplicação é de forma hierárquica. O controle começa na raiz e se move para baixo. É usado em um modelo sequencial.
  • Modelo do gerenciador: O controle dos objetos na aplicação é feito com apenas um objeto. Geralmente, é implementado em modelos concorrentes. Também pode ser implementado em modelo sequencial usando instrução case .
Vantagens
  • A lógica do aplicativo está em um só lugar.
Desvantagens
  • A lógica de controle pode ficar excessivamente complexa
  • Os controladores podem se tornar dependentes do conteúdo dos detentores de informações
  • Objetos podem ser acoplados indiretamente através das ações de seu controlador
  • O único trabalho interessante é feito no controlador
Quando usar

Quando as decisões a serem tomadas são poucas, simples e relacionadas a uma única tarefa.

Estilo de controle delegado

Um estilo de controle delegado está entre um estilo de controle centralizado e disperso. Ele passa parte da tomada de decisão e grande parte da ação para objetos que cercam um centro de controle. Cada objeto vizinho tem um papel significativo a desempenhar. Também pode ser chamado de modelo orientado a eventos, onde o controle é delegado ao objeto que o solicita para processar o evento.

Tipos[referência]
  • Modelo de transmissão: um evento é transmitido para todos os objetos no aplicativo. O objeto que pode manipular o evento pode adquirir o controle.
  • Modelo orientado a interrupção: Haverá o manipulador de interrupção para processar a interrupção e passar para algum objeto para processá-la.
Vantagens
  • É fácil de entender.
  • Embora haja um coordenador externo, os objetos podem ser mais inteligentes para saber o que devem fazer e podem ser reutilizados em outras aplicações.
  • Os coordenadores delegantes tendem a conhecer menos objetos do que os controladores dominantes.
  • Os diálogos são de nível superior.
  • É fácil alterar, pois as alterações geralmente afetam menos objetos.
  • É mais fácil dividir o trabalho de design entre os membros da equipe.
Desvantagens
  • Muita distribuição de responsabilidade pode levar a objetos fracos e colaborações fracas
Quando usar

Quando se quer delegar trabalho a objetos mais especializados.

Estilo de controle clusterizado

Este estilo de controle é uma variação do estilo de controle centralizado em que o controle é fatorado entre um grupo de objetos cujas ações são coordenadas. [19] A principal diferença entre um estilo de controle agrupado e delegado é que em um estilo de controle agrupado, os objetos de tomada de decisão estão localizados dentro de um centro de controle, enquanto em um estilo de controle delegado eles estão principalmente fora. [20]

Estilo de controle disperso

Um estilo de controle disperso não contém nenhum centro de controle. A lógica é espalhada por toda a população de objetos, mantendo cada objeto pequeno e criando o menor número possível de dependências entre eles. [21]

Vantagens
  • Nenhum
Desvantagens
  • Quando você deseja descobrir como algo funciona, deve rastrear a sequência de solicitações de serviços em vários objetos
  • Não muito reutilizável porque nenhum objeto contribui muito
Quando usar

Nunca.

Estilo de controle preferido

Após extensos resultados dos experimentos realizados, apenas a alta administração possui as habilidades necessárias para fazer uso do estilo de controle delegado e o estilo de controle centralizado beneficia os programadores. Não há nenhum contexto mencionado sobre os funcionários de nível médio. [17]

Referências

  1. ^ Wirfs-Brock, Rebecca; Wilkerson, Brian (1989). "Design Orientado a Objetos: Uma Abordagem Orientada à Responsabilidade". Avisos ACM SIGPLAN . 24 (10): 74. doi : 10.1145/74878.74885 .
  2. ^ Anthony JH Simons; Monique Snoeck; Kitty Hung (1998). "Padrões de design como papel de tornassol para testar a força dos métodos orientados a objetos" . Oois'98 . pp. 129-147. CiteSeerX 10.1.1.130.8713 . doi : 10.1007/978-1-4471-0895-5_10 . ISBN  978-1-85233-046-0.
  3. ^ Steven R. Haynes; Isaac G. Councill; Frank E. Ritter (2004). "Engenharia Explicativa Orientada à Responsabilidade para Modelos Cognitivos" .
  4. ^ Wirfs-Brock, Rebecca; McKean, Alan (2003). Design de Objetos: Funções, Responsabilidades e Colaborações . Indianápolis, IN: Addison-Wesley. ISBN 978-0201379433.
  5. ^ a b c d e Wirfs-Brock & McKean 2002 , pp. 3
  6. ^ Wirfs-Brock & McKean 2002 , pp. 58
  7. ^ a b c Wirfs-Brock & McKean 2002 , pp. 61
  8. ^ a b Wirfs-Brock & McKean 2002 , pp. 72
  9. ^ a b Wirfs-Brock & McKean 2002 , pp. 17
  10. ^ a b Wirfs-Brock & McKean 2002 , pp. 126
  11. ^ a b c Wirfs-Brock & McKean 2002 , pp. 168
  12. ^ Wirfs-Brock & McKean 2002 , pp. 340
  13. ^ a b c d e Wirfs-Brock & McKean 2002 , pp. 4
  14. ^ a b c d e f Wirfs-Brock & McKean 2002 , pp. 93
  15. ^ a b c Wirfs-Brock & McKean 2002 , pp. 165
  16. ^ Wirfs-Brock & McKean 2002 , pp. 164
  17. ^ a b Eric, Arisholm; Dag IK, Sjoberg (2004). "Avaliando o efeito de um estilo de controle delegado versus centralizado na manutenção do software orientado a objetos". Transações IEEE em Engenharia de Software . 30 (8): 521-534. doi : 10.1109/TSE.2004.43 . S2CID 6396127 . 
  18. ^ Wirfs-Brock & McKean 2002 , pp. 196
  19. ^ Wirfs-Brock & McKean 2002 , pp. 197
  20. ^ Wirfs-Brock & McKean 2002 , pp. 213
  21. ^ Wirfs-Brock & McKean 2002 , pp. 30

Bibliografia

Recuperado de " https://en.wikipedia.org/w/index.php?title=Responsibility-driven_design&oldid=1067732513 "
0.052760124206543