modelado basado en la responsabilidad versus razones de clase para cambiar

Question

En este texto que leí

  

Esté alerta a un componente que es justo   Una responsabilidad glorificada. UNA   se supone que el componente para capturar una   abstracción que tiene un propósito en el   sistema. Puede suceder que   Aparece en un momento como un significativo   componente es en realidad sólo una sola   La responsabilidad queda por sí sola. Ese   responsabilidad podría ser asignada a una   componente.

Esto me confunde. Si una clase debería tener una sola razón para cambiar, parece que debería tener una responsabilidad. Pero ahora parece que estoy tomando esto demasiado estrecho. ¿Puede de alguna manera dar una explicación de la responsabilidad y la razón para cambiar en el contexto del modelado basado en la responsabilidad? ¿Puede una clase tener más de dos responsabilidades y aún tener una razón para cambiar (o al revés)?

Answer 1

Lea acerca del modelado (o diseño) de Responsabilidad-Clase-Colaboración

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

Una clase puede tener varias responsabilidades. Siempre representa una única "cosa".

La " una razón para cambiar " La regla no se aplica a las responsabilidades. Periodo.

La " una razón para cambiar " la regla se debe utilizar de la siguiente manera.

1. No significa " 1 " ;. Significa " lo menos posible " ;.

2. Se aplica a la interfaz " " o " abstracción subyacente " o " concepto " para una clase Una clase debe encapsular algunos conceptos. Cuando eso cambia el concepto central, la clase cambia.

3. Muchas cosas simples son mejores que unas pocas cosas complejas. Es más fácil volver a combinar y modificar cosas simples.

4. Dentro de cada cosa compleja hay muchas cosas simples que tratan de ser libres.

5. Es difícil definir " simple " ;, pero " un concepto " está cerca. " una cosa para cambiar " También es una prueba útil para " simplicidad " ;.

6. Finalmente, " una razón para cambiar " no significa literalmente " 1 " ;.

Answer 2

De la forma en que lo entiendo, el peligro de "glorificar una responsabilidad a un componente" significa que debe tener cuidado de no traducir las responsabilidades a los componentes del sistema directamente.

Por ejemplo, en un sistema de correo electrónico, el usuario puede acercarse al sistema con el objetivo de iniciar un mensaje a un destinatario. Es responsabilidad del sistema hacer esto posible.

El usuario también puede acercarse al sistema para leer y responder un correo electrónico. También es responsabilidad del sistema hacer esto posible.

Pero esto significa que debe haber dos componentes " iniciar un nuevo correo electrónico " y " responder al correo electrónico " ¿en el sistema? No. Un general " redactar correo electrónico " El componente podría manejar ambos requisitos.

Entonces, en este caso, el componente " redactar correo electrónico " es responsable de los objetivos del usuario " iniciar correo nuevo " y " responder al correo " ;. Pero solo tendría que cambiar si cambia su concepto central (" cómo se componen los correos electrónicos ").

Vuelve a mirar detenidamente la siguiente frase de Cockburn: " Se supone que un componente captura una abstracción que tiene un propósito en el sistema " ;. Un propósito en el sistema (motivo para cambiar) no es lo mismo que el propósito de satisfacer una meta del usuario (responsabilidad).

Para resumir la larga historia: en lo que a mi entender, un componente tiene idealmente un concepto central. Puede tener varias responsabilidades. Pero como lo veo, la única responsabilidad no puede ser asignada a más de un componente.