modelling and responsibility

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

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

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

Answer 2

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 3

"...Many 'real world'-objects don't seem to have a clear responsibility..."

Remember, when you write software you're modeling the real world. Models can be simple or complex, with varying degrees of fidelity to things we observe. The important thing is capturing the behavior that you're trying to inject into your software system. You're free to leave out features that don't advance your goals. You're also free to "reify" features that don't have physical analogs.

Models in physics are also judged by their ability to explain phenomena and predict behavior in new areas. The success or failure of a software model is its ability to simulate the desired behavior and accept future change gracefully.

Remember, there are many ways to model any system in software. There isn't a single correct answer.

Answer 4

I've come to one conclusion during OOP design, and that's that it doesn't always pay to think too hard about modelling since it can lead you away from solving the problem.

The advantages of a good model are primarily readability, extensibility and reusability.

First think about what you need to do in the end, then try to apply these principles to your model as you go. Don't try too hard, if you need to do a bit of refactoring later, so be it. You could lose too much valuable time wrapping your head around the "perfect" model.

As for the bank account, think about it this way, if you were a banker, what would you expect from an actual account? Then try to upgrade an empty object or objects to slowly accomodate the requirements.

You can think of a model as exactly that - an abstract formation with defined behaviour. Its responsibilites are part of that behaviour, usually the part visible to the outside world.

The way I see it, only you can decide what's the right model when designing it.

Well, my two cents anyway.

Answer 5

The problem with your question, koen, is that you are asking it after creating the class, when in fact this is one of the fundamental questions you should ask yourself when trying to create a new class.

In any case, I respectfully disagree with our colleagues above. The answers from Meredith and Neil define class contracts, not responsibilities. A class responsibility is defined as any public service the class offers without any regard to a particular implementation. It replaces the notion of functionality and essentially describes very succinctly each of the class public methods. So examples of a class responsibility, could be:

• Fetch first element in a list
• Sort list of debts
• Notify Observer class

A class contract, on the other hand is defined by the sum of the class responsibilities. And examples are given by Meredith and Neil.

Answer 6

Keep the thinking simple & think aloud. Thumb rule for identifying responsibilities (start from a set of simple actions):

ask the following questions (in fact a lot of questions) on the modeled object:

• Can the object come to live by itself? Or is it an instrument for a transaction? Does it make sense only when working with other objects? (Dependency factor)

• What can the object do by itself?

• What actions can be performed on the object by other objects?

• what can be done to the object, to its data or its state?

(ie) an account can't debit / credit itself. that simply doesn't make sense. But it can be used as the instrument to be debited / credited by the system or the banker or the customer.

Identify actions by looking from different perspectives, based on who'll be using this object and for what purpose (ie., an account object from the eyes on a banker, from the eyes of a customer, from the eyes of a system - etc.)

"a bank account acts as a common instrument for transaction between the customer and the bank - both using it from different perspectives. The bank uses it as a key to manage the customers' monies while the customer uses it as an instrument to transact."

What is deposit / withdrawal to a customer is debit / credit for the bank. And the bank would be using the account for various internal purposes (ex. notify the customer on their salary credit with an alert) while the customer actions for the account is limited.

Try to form simple sentences - out of the objects collaborating with others - if they are meaningful, you are good. if not, rethink.

A Bank account,

1. Is owned by a Customer - who can possibly
   • deposit money
   • withdraw money
   • check the balance
   • can issue a cheque from his account
   • can transfer amounts to other accounts
   • can pay bills
   • can get his salary credited to the account
   • can get overdrafts
2. Belongs to the bank - which can possibly
   • use the account as an instrument to track the monies and transactions of the account
   • stores and maintains all the account & money information
   • restricts access to the account holder & provides security for their money
   • etc.

cheers
-sundar