Determining Class Responsibility and Collaborators

Question

I'm using ActiveRecord to maintain information about users. The User class has the expected load(), insert(), update(), and delete() methods, setters, getters, and a few others. But I am having trouble deciding whether or not certain other methods should be included in the User class, or handled by collaborators.

Here's an example:

There are several transactions that a user might request that require confirmation. This is handled in a conventional way -- sending an email to the user with a link; clicking the link confirms that the user does indeed want the transaction to proceed. A hash of the verification key and it's expiration date/time persist as part of the user record.

Where should I draw the line in this process? Should there be a collaborator that handles verification (for example by taking the plain-text verification key from the query string and accepting a User object as a param)? Or should this be handled internally by the User class (passing the plain-text verification key in a method call)?

The very next thing that would happen upon verification, of course, is that the transaction would proceed requiring an update to the active record -- and there, it seems to me, the User class must have responsibility.

Any suggestions?

Answer 1

You should delegate this task to a collaborator, which manages a confirmations table.

You would use the Confirmation model to track all confirmation requirements. The model will belong to User, as well as manage the confirmation hash and the action-to-be-confirmed (e.g. activate_account, change_password or change_email etc.).

The Confirmation controller would be responsible for validating the confirmation hash and chaining the appropriate action on the appropriate model (e.g. activate_account -> user.activate(), change_password -> user.setPassword() etc.) and remove the Confirmation from the confirmations table upon successful completion.

This will allow for better separation of logic, as well as allow you to scale better, e.g. to entertain more than one pending confirmation for a given user (say confirmation to change password and confirmation to change something else.)