Design choice

What are the advantages and disadvantages when using either one of the following:
payer.transfer(payee, amount); vs. transfer(payer, payee, amount);

Regarding this simple example, my interest is toward the design, dependencies, abstraction etc...

Appreciate your comments and resources pointed out!

Comments

[Rahul Barwal]

payer.transfer(payee, amount);

• We are sure that payer exists.
• Better for situations with individuals and their transactions.

transfer(payer, payee, amount);

• Needs checks to be sure whether the payer is there or not.
• Better when we have a large no of payers(may be in an array).
• In bigger repositories it comes in handy, when you have defaults in place for payer. Obviously this does not make much sense for this particular example. But I've faced some situations where if the argument comes then behaviour is something else we have to switch to default.

As you can see there are pros and cons to both, personally I would prefer second approach as it gives us the flexibility to have defaults.
Most of the library developers tend to provide both the approaches.

[Dario Javier Rick]

In the first case, you use the payer as an entity, and in the other case the entity is the transfer itself. The question that i would consider is: "Could the transfer exists without the payer?" I think it couldnt, but the payer can exists by itself, because normally you want to store data about the client prior to the transfer.

As always, there is not a clear answer. Developing software is a logical process, but also has creative influence. Each developer has a different point of view, and all of them could solve the same problem with different focus. And I think that's the most enjoyable thing about design