Why Too Many Overloads Can Be a Bad Thing
At work we're using code generation to create our data access layer. So for the users table we have a UsersDalBase with many overloads of methods such as Add(User) and Add(IList<User>). Thing is, many time we need to override the default behavior of a method. For instance we might want to change Add(User) to notify the user by mail, write something to a log, use caching, etc. We do that in a UsersDal class that inherits from UsersDalBase.
But hmm, that other overload that accepts a list of users is still there. No one uses it for now, but they might try to in the future. Still, it probably wouldn't have been written if it hadn't been for code-generation. So should we also update Add(IList<User>) with all the changes (mails, caching...)? The implementation is more difficult than the single entity case and we would have to add tests for that too.
I had a bitter argument with a member of my team on this very subject the other day. He claimed that we must update both methods since they're there and might be used, and if we don't, we won't get notification and caching in that case. I claimed that it is foolish to waste time on methods that will probably never be used. No where in the system do we add more than one user at the time. The purpose of the many overloads the code-generation gives us is to help us by giving us many options, not hinder us.
At the end we agreed to throw a NotSupportedException when someone tries to add more than user at a time. This way we don't have to write unneeded code, but we are also not concerned that someone in the future will ill-use the class.