I agree wholeheartedly with your reasoning and example.
In fact my next post is going to be on constraining user input through the use of custom parameter classes.

I don’t think what I am talking about in my post and what you are saying here are necessarily mutually exclusive though. It kind of depends on the situation and what data your storing and how your API is interacted with. I could easily see a login method that takes in a fullName, but is an additional method instead of an overload.

I agree also that you can store parameters in the class instance, but you will still have to get them in there somehow. Which can jump move the problem up to overloaded constructors.

Good points though excellent discussion.

I don’t necessarily see that as a bad thing.
Consider the following method:
public void DoSomethingWithUser(string firstname, string middlename, string lastname, int age);

When reading that, how do you know which string is which. What if the creator of that method decides to swap the name string. You get no compiletime checks, and the signature is harder to read.
Now, take this method signature instead. It is much easier to read and you know just by reading the signature what it accepts, plus it gives you compiletime checks if you decide to move the parameter.
public void DoSomethingWithUser(Name fullName, int age);

Btw, we’ve all been under the assumption that you have to pass in the parameters into the method. In many cases, you’d want to do that, but sometimes wouldn’t it be better to have the class statefull instead.
Case in point, lets take the Login example. Do you REALLY need to send in the parameters? Can’t you just store the parameters in the class instance instead. That would mean the login method would have no parameters. Nothing beats that .
It won’t work all the time in all usecases, but it is something you should consider when you create your api/system.

“The usual case for [Replace Parameter with Explicit Methods] is that you have discrete values of a parameter, test for those values in a conditional, and do different things. The caller has to decide what it wants to do by setting the parameter, so you might as well provide different methods and avoid the conditional. You not only avoid the conditional behavior but also gain compile time checking. Furthermore your interface also is clearer. With the parameter, any programmer using the method needs not only to look at the methods on the class but also to determine a valid parameter value. The latter is often poorly documented.”

This isn’t directly related to overloaded methods, but I believe that overloaded methods are near equivalent to one method with several conditional parameters.

With .Net 40 and optional parameters, this is taken to the next level of complexity. I guess we’ll just have to see how they will scale and be maintained.

Wasn’t one of the reasons for optional parameters was to help with the complexity for COM operability?

1) Overloaded methods should have exactly the same behavior.
2) Since overloaded methods have the same behavior all methods can be implemented in terms of one of the methods, usually this is the method that takes the most low level parameters.

A good example of this pattern is the System.IO.TextWriter class. All implementations of Write and WriteLine eventually boil down to uses of the Write(char) method.

I would prefer to use the TextWriter as written, rather than a class with umpteen methods like WriteInt32, WriteLong, WriteChar, WriteDouble, etc.

I also want to note that I agree with you John, on the trying to make a cleaner API. One thing I am a fan of is the new push for fluent interfaces. (http://msdn.microsoft.com/en-us/magazine/ee291514.aspx) I think in some ways this follows some of the same principles you layout in your article.

I do however think that if you name your parameters correctly their intent will be obvious. Another thing I like about optional/named parameters is their ability to be expressive on the calling side. Much like object initializers are used in the article link above so can optional/named parameters.

I guess I would concede the iPhone discussion saying there are two buttons. The [] button and the screen itself. I get your point about simplicity I am just having a hard time drawing the parallel between hardware and software.