modelagem baseada responsabilidade contra razões de classe para a mudança

Question

Na este texto li

Esteja alerta para um componente que é apenas uma responsabilidade glorificado. UMA componente é suposto uma captura abstração que tem um propósito na sistema. Pode acontecer que o que aparece em um momento como uma significativa componente é realmente apenas uma única responsabilidade à esquerda na sua própria. Este responsabilidade poderia ser atribuída a um componente.

Isso me confunde. Se uma classe deve ter apenas uma razão para a mudança, parece que ele deve ter um responsabilidade. Mas agora parece que eu estou levando isso muito estreito. Pode de alguma forma dar uma explicação de responsabilidade e razão para a mudança no contexto de responsabilidade baseado modelagem? Pode uma classe tem mais de duas responsabilidades e ainda ter uma razão para a mudança (ou o contrário)?

Answer 1

Leia sobre modelagem Classe-Responsabilidade-Colaboração (ou design)

http://www.agilemodeling.com/artifacts/crcModel.htm

http://alistair.cockburn.us/Using+CRC+cards

http: //users.csc.calpoly. edu / ~ jdalbey / SWE / CaseStudies / ATMSim / CRCmodel.html

http://c2.com/doc/oopsla89/paper.html

Uma classe pode ter várias responsabilidades. Ele sempre representa uma "coisa" single.

O "uma razão para a mudança" regra não se aplica às responsabilidades. Período.

O "uma razão para a mudança" regra deve ser usado da seguinte maneira.

1. Isso não significa que "1". Significa "o mínimo possível".

2. Aplica-se à "interface" ou "abstração subjacente" ou "conceito" para uma classe. A classe deve encapsular alguns conceitos. Quando que as mudanças conceito central, a classe muda.

3. Muitas coisas simples são melhores do que algumas coisas complexas. É mais fácil de recombinar e modificar as coisas simples.

4. Dentro de cada coisa complexa muitas coisas simples que tentam ser livre.

5. É difícil definir "simples", mas "um conceito" está perto. "Uma coisa é mudança" é também um teste útil para a "simplicidade".

6. Finalmente, "uma das razões para a mudança" não significa literalmente "1".

Answer 2

A forma como eu entendo, o perigo de "glorificar a responsabilidade de um componente" significa que você precisa ter cuidado para não traduzem responsabilidades para os componentes do sistema diretamente.

Por exemplo, em um sistema de e-mail, o usuário pode aproximar o sistema com o objetivo de iniciar uma mensagem para um destinatário. É responsabilidade do sistema para tornar isso possível.

O usuário também pode aproximar o sistema para ler e responder a um e-mail. É responsabilidade do sistema para tornar isso possível, também.

Mas isso significa que não há necessidade de ser dois componentes "iniciar novo e-mail" e "responder a e-mail" no sistema? Não. Um componente geral "e-mail compor" seria capaz de lidar com ambos os requisitos.

Portanto, neste caso, o componente "email compor" é responsável pelos objetivos do usuário "iniciar novo e-mail" e "responder e-mails". Mas ele só precisaria mudar se as suas mudanças conceito de núcleo ( "como e-mails são compostas").

Olhe novamente de perto a seguinte frase por Cockburn: "Um componente é suposto para capturar uma abstração que tem um propósito no sistema". A propósito no sistema (razão para mudança) não é o mesmo que o propósito de satisfazer uma meta de usuário (responsabilidade).

Para fazer a longa história curta: Como o meu entendimento, um componente idealmente tem um conceito central. Pode ter várias responsabilidades. Mas a meu ver, a única responsabilidade não pode ser atribuída a mais de um componente.