I agree with Darien’s answer, but wanted to add a point of view from a C# programmers perspective.
When I see code which says ‘setXXX’ I read that to say that it’s setting a value on a thing, I don’t expect this to have side effects in that thing other than setting that value, and I do expect this to be idempotent (ie I can keep setting it with the same value and it’s okay). It’s rather like accessing a field. Generally I’d also expect to see a ‘getXXX’ method along with a ‘setXXX’.
I don’t know if this is what you expect in Java and C++, but that’s what I’d expect in C#, albeit in C# there’s a short hand for this called Properties. And here’s some nice guidance on how to use Properties (http://msdn.microsoft.com/en-us/library/ms182181.aspx).
Given this view, then the interface I’d choose depends purely on if there are any side effects (other than changing that field value):
If performing the action has side effects, for example it’s showing a dialog box then I’d go with “Show()”, and “Hide()”.
If it doesn’t have side effects, say I’m setting the visibility of a “widget” and something else renders that widget depending on it’s state then I’d use setVisibility or setIsVisible. (I wouldn’t call it SetVisible).
In C# (not sure about Java) it’s pretty common to adopt an observer pattern, where a UI framework will listen for changes to objects and will automatically re-render the UI when a property such as Visibility changes. That means that setting the value by calling setIsVisible appears as if it has side effects, but in my definition it doesn’t. The widget’s contract is fulfilled by setting it’s field value representing “IsVisible”.
Put another way, it’s okay for me to toggle the visibility of a label on a form before the form is shown. Ie label.getIsVisible == true, but the form isn’t shown.
It’s not okay for me to call Hide() when the form isn’t being shown.
