modellazione e responsabilità

Question

Diciamo che si desidera creare un modello di un conto bancario nella propria applicazione. Puoi creare una classe BankAccount che fa quello che fa un tipico conto bancario. Ma se ti viene chiesto qual è la responsabilità della classe, qual è la risposta? "Comportarsi come un conto in banca?" Non è molto concreto. Sono un po 'confuso sulla relazione tra modellizzazione e responsabilità. Molti oggetti del "mondo reale" non sembrano avere una chiara responsabilità.

Qual è il modo migliore per iniziare a modellare tali concetti e mantenere responsabilità ben definite?

Answer 1

Smontare cosa "comportarsi come un conto in banca "significa. Un conto bancario potrebbe aver bisogno di essere in grado di:

• tenere traccia di quanti soldi è in esso
• visualizzazione che le informazioni a qualcuno che ha i privilegi corretti (il proprietario dell'account, o un impiegato di banca)
• ricevere depositi
• tenere traccia di quando un deposito è accaduto
• fornire al depositante la conferma che il deposito è stato elaborato correttamente (con diversi livelli di privilegio - il proprietario dell'account potrebbe ottenere il nuovo totale e un numero di conferma, un terzo la festa potrebbe ricevere solo una conferma mber)
• dare soldi a (cioè, i ritiri di processo per) un utente correttamente autenticato
• tenere traccia di quando un ritiro avvenuto
• non dare i soldi quando l'equilibrio è insufficiente
• ritirare il denaro automaticamente da un account di backup per la protezione di scoperto
• e così via ...

Da questo, si può astratti (refactoring) alcuni di questi compiti (responsabilità) in modelli più generali, ad es. "un'entità che può essere autenticata a diversi livelli di privilegio", "un'entità che può comunicare con altre entità del suo tipo al livello di privilegio appropriato", "un'entità che può registrare quando il suo stato cambia e quale cambiamento si è verificato", e così via.

Capire quali sono le attività sono le storie degli utenti, nel modello di sviluppo Agile. Però non devi bere l'Agile kool-aid per usare questa tecnica; è semplicemente un modo ragionevole per capire quali sono le esigenze di un progetto. Esaminando criticamente il modo in cui gli utenti interagiranno con il tuo software e definendo concretamente ciò che tali interazioni porteranno a do, è il primo passo per progettare il software.

Answer 2

esempi conto bancario di responsabilità, la parte superiore della mia testa:

• mantengono titolare del conto informazioni
• mantenere l'elenco delle transazioni
• forniscono saldo corrente

Answer 3

"... Molti oggetti del" mondo reale "non sembrano avere una chiara responsabilità ..."

Ricordate, quando si scrive un software che sei modellazione il mondo reale. I modelli possono essere semplici o complesse, con vari gradi di fedeltà alle cose che osserviamo. La cosa importante è catturare il comportamento che si sta cercando da iniettare nel tuo sistema software Sei libero di escludere funzionalità che non portano avanti i tuoi obiettivi Sei libero di "reificare" funzioni che non hanno analoghi fisici

Anche i modelli in fisica sono giudicato dalla loro capacità di spiegare i fenomeni e prevedere il comportamento in nuove aree. Il successo o il fallimento di un modello software è la sua capacità di simulare il comportamento desiderato e accettare il cambiamento futuro con garbo

Ricordate, ci sono molti modi per modellare qualsiasi sistema nel software. Non c'è una sola risposta corretta.

Answer 4

Sono giunto a una conclusione durante la progettazione OOP, e cioè che non sempre si paga per pensare troppo duro sulla modellazione dal momento che può portarti via dal risolvere il problema.

I vantaggi di un buon modello sono principalmente la leggibilità, l'estensibilità e la riusabilità.

Prima pensa a ciò che devi fare alla fine, quindi prova ad applicare questi principi al modello mentre procedi. Non tentare troppo, se hai bisogno di fare un po 'di refactoring più tardi, così sia. Potresti perdere troppo tempo prezioso avvolgendo la testa attorno al modello "perfetto".

Per quanto riguarda il conto bancario, pensateci in questo modo, se foste un banchiere, cosa vi aspettereste da un conto effettivo? Quindi provare ad aggiornare un oggetto o gli oggetti vuoti per soddisfare lentamente i requisiti.

Si può pensare ad un modello esattamente come questo: una formazione astratta con un comportamento definito. Le sue responsabilità sono parte di quel comportamento, di solito la parte visibile al mondo esterno.

Il modo in cui lo vedo, solo tu puoi decidere qual è il modello giusto quando lo si progetta.

Beh, i miei due centesimi comunque.

Answer 5

Il problema con la tua domanda, koen, è che lo stai chiedendo dopo aver creato la classe, quando in realtà questa è una delle domande fondamentali che dovresti porci quando cerchi di creare una nuova classe.

In ogni caso, sono rispettosamente in disaccordo con i colleghi di cui sopra. Le risposte di Meredith e Neil definiscono i contratti di classe , non le responsabilità. Una responsabilità di classe è definita come qualsiasi servizio pubblico offerto dalla classe senza alcun riguardo per una particolare implementazione. Sostituisce la nozione di funzionalità e essenzialmente descrive in modo molto sintetico ciascuno dei metodi pubblici di classe. Quindi, esempi di una responsabilità della classe, potrebbe essere:

• Fetch primo elemento in un elenco
• Ordina lista dei debiti
• Segnalatemi classe Observer

Un contratto di classe, d'altra parte è definito dalla somma delle responsabilità di classe. E gli esempi sono dati da Meredith e Neil.

Answer 6

Mantenere il pensiero semplice & pensare ad alta voce. regola del pollice per l'identificazione delle responsabilità (a partire da un insieme di azioni semplici):

porsi le seguenti domande (di fatto un sacco di domande) sull'oggetto modellato:

• Può l'oggetto venire a vivere da solo? O è uno strumento per una transazione? Ha senso solo quando si lavora con altri oggetti? (Fattore di dipendenza)

• Cosa può fare l'oggetto da solo?

• Quali azioni possono essere eseguite sull'oggetto da altri oggetti?

• cosa può essere fatto all'oggetto, ai suoi dati o al suo stato?

(ad esempio) un account non può addebitare/accreditare se stesso. questo semplicemente non ha senso. Ma può essere utilizzato come strumento da addebitare/accreditare dal sistema o dal banchiere o dal cliente.

Identificare le azioni guardando da diversi punti di vista, in base a chi utilizzerà questo oggetto e per quale scopo (ad esempio, un oggetto account dagli occhi su un banchiere, dagli occhi di un cliente, dagli occhi di un sistema - ecc.)

"un conto bancario funge da strumento comune per le transazioni tra il cliente e la banca, sia utilizzandolo da diversi punti di vista: la banca lo utilizza come chiave per gestire il denaro dei clienti mentre il il cliente lo usa come strumento per le transazioni ".

Qual è il deposito/prelievo per un cliente è debito/credito per la banca. E la banca avrebbe utilizzato l'account per vari scopi interni (ad esempio, notificare al cliente il proprio credito di stipendio con un avviso) mentre le azioni del cliente per l'account sono limitate.

Provare a formare frasi semplici - fuori dagli oggetti che collaborano con gli altri - se sono significativi, sei bravo. in caso contrario, ripensare.

conto

una banca,

1. è di proprietà di un cliente - che può eventualmente
   • deposito di denaro
   • prelevare denaro
   • controllare il saldo
   • può emettere un assegno dal suo account
   • può trasferire importi ad altri account
   • può pagare le bollette
   • può ottenere il suo stipendio accreditati sul conto
   • può ottenere scoperti
2. appartiene alla banca - che può eventualmente
   • utilizzare l'account come strumento per tenere traccia il denaro e le transazioni dell'account
   • memorizza e gestisce tutto il conto & informazioni denaro
   • limita l'accesso al titolare del conto & fornisce la sicurezza per i loro soldi
   • ecc

applausi
-sundar