modellizzazione basata sulla responsabilità rispetto a motivi di classe per cambiare

Question

In questo testo che ho letto

  

Stai attento a un componente che è giusto   una responsabilità glorificata. UN   componente dovrebbe catturare un   astrazione che ha uno scopo nel   sistema. Può succedere che cosa   appare in un momento come significativo   componente è davvero solo un singolo   responsabilità lasciata da sola. Quello   la responsabilità potrebbe essere assegnata a   componente.

Questo mi confonde. Se una classe dovrebbe avere solo una ragione per cambiare, sembra che dovrebbe avere una responsabilità. Ma ora sembra che lo stia prendendo troppo stretto. Può in qualche modo fornire una spiegazione della responsabilità e della ragione per cambiare nel contesto del modello basato sulla responsabilità? Una classe può avere più di due responsabilità e avere ancora una ragione per cambiare (o viceversa)?

Answer 1

Leggi informazioni sulla modellizzazione (o progettazione) della classe-responsabilità-collaborazione

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 classe può avere diverse responsabilità. Rappresenta sempre un'unica "cosa".

L'unica ragione per cambiare " la regola non si applica alle responsabilità. Periodo.

L'unica ragione per cambiare " la regola dovrebbe essere usata come segue.

1. Non significa " 1 " ;. Significa " il meno possibile " ;.

2. Si applica all'interfaccia " " o "astrazione sottostante" o "concetto" per una lezione. Una classe dovrebbe incapsulare alcuni concetti. Quando il concetto di base cambia, la classe cambia.

3. Molte cose semplici sono meglio di alcune cose complesse. È più facile ricombinare e modificare cose semplici.

4. All'interno di ogni cosa complessa ci sono molte cose semplici che cercano di essere libere.

5. È difficile definire "semplice", ma "un concetto" è chiuso. " una cosa da cambiare " è anche un test utile per "semplicità".

6. Infine, "un motivo per cambiare" non significa letteralmente " 1 " ;.

Answer 2

Il modo in cui lo capisco, il pericolo di "glorificare una responsabilità verso un componente" significa che devi stare attento a non tradurre direttamente le responsabilità in componenti di sistema.

Ad esempio, in un sistema di posta elettronica, l'utente può avvicinarsi al sistema con l'obiettivo di avviare un messaggio a un destinatario. È responsabilità del sistema renderlo possibile.

L'utente può anche avvicinarsi al sistema per leggere e rispondere a un'email. È responsabilità del sistema rendere possibile anche questo.

Ma questo significa che ci devono essere due componenti "avviare una nuova e-mail" e " rispondi all'email " nel sistema? No. Un'email generale di "comporre" componente sarebbe in grado di gestire entrambi i requisiti.

Quindi, in questo caso, il componente "componi email" è responsabile degli obiettivi dell'utente " inizia nuova posta " e "rispondi alla posta". Ma dovrebbe cambiare solo se cambia il suo concetto di base ("come sono composte le e-mail").

Guarda di nuovo attentamente la seguente frase di Cockburn: "Un componente dovrebbe catturare un'astrazione che ha uno scopo nel sistema". Uno scopo nel sistema (motivo della modifica) non è uguale allo scopo di soddisfare un obiettivo dell'utente (responsabilità).

Per farla breve: per quanto riguarda la mia comprensione, un componente ha idealmente un concetto centrale. Potrebbe avere diverse responsabilità. Ma a mio avviso, l'unica responsabilità non può essere assegnata a più di un componente.