Prefer non-member non-friend functions... in Java?

Question

Disclaimer: this question is directed as those who would consider Scott Meyers' advice in Item 23 of Effective C++ to be good OO design -- at least in C++.

In Java, where global functions do not exist, it might seem at first that this principle isn't applicable, but it seems to me that it is. Take Scott Meyers' own example.

public class WebBrowser {
    public void clearCache() {}
    public void clearHistory() {}
    public void removeCookies() {}
}

By creating an associated "namespace" class containing a static convenience method, I have increased the encapsulation of WebBrowser by minimizing the amount of code which can access its internals. After all, static methods in Java are essentially global functions (assuming everything in the class is public and static).

public class WebBrowserStuff {
    private WebBrowserStuff() {} // prevent instantiation

    public static void clearBrowser(WebBrowser browser) {
        browser.clearCache();
        browser.clearHistory();
        browser.clearRemoveCookies();
    }
}

The only downside I can see is that there is no argument-dependent lookup in Java, so calling the method is slightly more verbose.

WebBrowserStuff.clearBrowser(browser);

My question is, given that this use of non-member functions is desirable in C++ (see my disclaimer), is there any reason, other than increased verbosity, why you would not want to do this in Java? This question is specifically about the difference between C++ and Java regarding this technique.

I am not interested in hearing personal opinions on whether or not this is generally good object-oriented design, although I am interested in hearing if there are any cultural differences between C++ and Java that might cause general opinion to lean one way or the other.

[EDIT]

Unfortunately, I didn't really get an answer to my question, my edit to try and make it less opinion-based didn't stop it from being closed, so I can't pick an accepted answer. One could interpret this as that there is really no technical reason why you wouldn't want to do this (assuming it is good practice in C++), and any opposition to this technique is purely personal or a cultural Java thing.

Answer 1

No, this is not common in Java and it is not the way of doing it. The WebBrowserStuff you have created looks, in Java, like a bad implementation of the Singleton Pattern. One problem with your implementation is that you could create several instances of WebBrowserStuff. It seems like you only need one so you should use a Singleton.

Think if you want to have those methods in Browser. This seems the right way to proceed in your case. They should be part of Browser.

However, if you want to do a helper class make sure to make it a Singleton: Add a private constructor so nobody other than the class can create an instance and add a getInstance() method to get the instance.

Answer 2

WebBrowserStuff.clearBrowser(browser);

is a static method that is defined per-class and doesn't directly have access to an instance beyond the one that is passed. This requires another class for utility reasons. Generally within Java's libraries themselves this is only done when we are either working with a specialized type that can't deal with all of these static methods (Array objects contrasted with utilities in the Arrays class, or Collections, where we're working with a broad set of interfaces that shouldn't take static methods.

These helper classes are generally not good practice, and in your case, you can, and should, put clearBrowser as a non-static method of WebBrowser.

Now, this has been done, and while it isn't exactly good practice, it's technically valid, and there's no contractual obligation denying you this right. On that note, to meet with Java libraries' naming, I'd call the helper class WebBrowsers as the libraries generally take the class/interface in question and pluralize it for this naming purpose.

Answer 3

Acceptable, yes. Preferred, no. Here's why: static methods are by nature excluded from the overhead upon instancing - so it's pretty silly to make a new class just for some supporting methods on the WebBrowser class. If anything, add the static method to the WebBrowser class. This avoids the verbosity you were talking about, and keeps like things together. However, I also agree with Colin that if you are building this as a type of library or something to later be extended - then don't over-hide things at the start.