modelling and responsibility [closed]

Question

Let's say that you want to create a model of a bank account in your application. You could create a class BankAccount that does what a typical bank account does. But if you're asked what the responsability of the class is, what's the answer? 'Behaving like a bank account?' That's not very concrete. I'm a bit confused on the relationship between modeling and responsibility. Many 'real world'-objects don't seem to have a clear responsibility.

What's the best way to start modeling such concepts and keep well-defined responsibilities?

Answer 1

Take apart what "behaving like a bank account" means. A bank account might need to be able to:

• keep track of how much money is in it
• display that information to someone who has the correct privileges (the account owner, or a bank employee)
• receive deposits
• keep track of when a deposit happened
• provide the depositor with confirmation that the deposit was processed successfully (with varying levels of privilege -- the account owner might get the new total and a confirmation number, a third party might only get a confirmation number)
• give money to (i.e., process withdrawals for) a properly authenticated user
• keep track of when a withdrawal happened
• not give out money when the balance is insufficient
• withdraw money automatically from a backup account for overdraft protection
• and so on ...

From this, you can abstract (refactor) some of these tasks (responsibilities) into more general models, e.g. "an entity that can be authenticated to at different levels of privilege", "an entity that can communicate with other entities of its type at the appropriate privilege level", "an entity that can record when its state changes and what change occurred", and so on.

Figuring out what the tasks are is what user stories are for, in the Agile development model. You don't have to drink the Agile kool-aid in order to use this technique, though; it's simply a sensible way of figuring out what a project's requirements are. Critically examining how users will interact with your software, and concretely defining what those interactions will do, is the first step in architecting the software.

Answer 2

Bank account responsibility examples, off the top of my head:

• maintain account holder information
• maintain list of transactions
• provide current balance