Let's say I have a function IsAdmin that checks whether a user is an admin. Let's also say that the admin checking is done by matching user id, name and password against some sort of rule (not important).
In my head there are then two possible function signatures for this:
public bool IsAdmin(User user);
public bool IsAdmin(int id, string name, string password);
I most often go for the second type of signature, thinking that:
- The function signature gives the reader a lot more info
- The logic contained inside the function doesn't have to know about the
Userclass - It usually results in slightly less code inside the function
However I sometimes question this approach, and also realize that at some point it would become unwieldy. If for example a function would map between ten different object fields into a resulting bool I would obviously send in the entire object. But apart from a stark example like that I can't see a reason to pass in the actual object.
I would appreciate any arguments for either style, as well as any general observations you might offer.
I program in both object oriented and functional styles, so the question should be seen as regarding any and all idioms.
Best Answer
I personally prefer the first method of just
IsAdmin(User user)It's much easier to use, and if your criteria for IsAdmin changes at a later date (perhaps based on roles, or isActive), you don't need to rewrite your method signature everywhere.
It's also probably more secure as you aren't advertising what properties determine if a user is an Admin or not, or passing around the password property everywhere. And syrion makes a good point that what happens when your
iddoesn't match thename/password?The length of code inside a function shouldn't really matter providing the method does its job, and I'd much rather have shorter and simpler application code than helper method code.