modélisation basée sur la responsabilité par rapport aux raisons de classe pour changer

Question

Dans le ce texte que j'ai lu

  

Soyez attentif aux composants qui ne font que   une responsabilité glorifiée. UNE   composant est censé capturer un   abstraction qui a un but dans le   système. Il peut arriver que quoi   apparaît à un moment significatif   composant est vraiment juste un seul   responsabilité laissée à elle-même. Cette   la responsabilité pourrait être assignée à un   composant.

Cela me trouble. Si une classe ne doit avoir qu'une seule raison de changer, il semble qu'elle ne devrait avoir qu'une seule responsabilité. Mais maintenant, je prends ça trop étroit. Peut-on donner une explication de la responsabilité et des raisons de changer dans le contexte de la modélisation basée sur la responsabilité? Une classe peut-elle avoir plus de deux responsabilités tout en ayant une raison de changer (ou l'inverse)?

Answer 1

En savoir plus sur la modélisation (ou conception) collaboration responsabilité de classe

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

Une classe peut avoir plusieurs responsabilités. Il représente toujours une "chose" unique.

La "une raison de changer" la règle ne s'applique pas aux responsabilités. Période.

La "une raison de changer" Cette règle doit être utilisée comme suit.

1. Cela ne signifie pas "1". Cela signifie "aussi peu que possible".

2. Il s’applique à l’interface " interface " ou " abstraction sous-jacente " ou " concept " pour une classe. Une classe devrait résumer quelques concepts. Lorsque le concept de base change, la classe change.

3. Beaucoup de choses simples valent mieux que quelques choses complexes. Il est plus facile de recombiner et de modifier des choses simples.

4. À l'intérieur de chaque chose complexe, il y a beaucoup de choses simples qui essaient d'être libres.

5. Il est difficile de définir "simple", mais "un concept" est près. " une chose à changer " est également un test utile de "simplicité".

6. Enfin, "une raison de changer" ne signifie pas littéralement "1".

Answer 2

Comme je le comprends, le danger de "glorifier une responsabilité envers un composant" Cela signifie que vous devez faire attention à ne pas transférer directement les responsabilités aux composants du système.

Par exemple, dans un système de messagerie, l'utilisateur peut contacter le système dans le but d'initier un message à un destinataire. Le système est responsable de rendre cela possible.

L’utilisateur peut également s’adresser au système pour lire un courrier électronique et y répondre. Il incombe également au système de rendre cela possible.

Mais cela signifie-t-il qu'il doit y avoir deux composants "initier un nouveau courrier électronique"? et " répondre au courrier électronique " dans le système? N ° Un général " composer un email " composant serait capable de gérer les deux exigences.

Donc, dans ce cas, le composant "composer un email". est responsable des objectifs de l'utilisateur " créer un nouveau courrier " et "répondre au courrier". Mais il n’aurait besoin de changer que si son concept de base change ("comment sont composés les courriers électroniques").

Examinez à nouveau attentivement la phrase suivante de Cockburn: "Un composant est censé capturer une abstraction qui a une fonction dans le système". Un objectif dans le système (raison de changer) n’est pas le même que celui de satisfaire un objectif utilisateur (responsabilité).

Pour faire la longue histoire courte: En ce qui concerne ma compréhension, un composant a idéalement un concept de base. Il peut avoir plusieurs responsabilités. Mais à mon avis, une responsabilité ne peut être attribuée à plus d’un composant.