Предпочитаете не являющиеся членами не дружественные функции … в Java?
Отказ от ответственности: этот вопрос направлен тем, кто посчитал бы совет Скотта Мейерса в пункте 23 «Эффективного C ++» хороший ОО дизайн — по крайней мере, в C ++.
В Java, где глобальные функции не существуют, на первый взгляд может показаться, что этот принцип не применим, но мне кажется, что это так. Возьмите собственный пример Скотта Мейерса.
public class WebBrowser {
public void clearCache() {}
public void clearHistory() {}
public void removeCookies() {}
}
Создав связанный класс «пространства имен», содержащий статический удобный метод, я увеличил инкапсуляцию WebBrowser минимизируя количество кода, который может получить доступ к его внутренним элементам. В конце концов, статические методы в Java по сути являются глобальными функциями (при условии, что все в классе является общедоступным и статическим).
public class WebBrowserStuff {
private WebBrowserStuff() {} // prevent instantiation
public static void clearBrowser(WebBrowser browser) {
browser.clearCache();
browser.clearHistory();
browser.clearRemoveCookies();
}
}
Единственный недостаток, который я могу видеть, это то, что в Java нет поиска, зависящего от аргументов, поэтому вызов метода немного более многословен.
WebBrowserStuff.clearBrowser(browser);
Мой вопрос заключается в том, что, учитывая, что использование функций, не являющихся членами, желательно в C ++ (см. Мой отказ от ответственности), есть ли какая-либо причина, кроме повышенной детализации, почему вы не захотите делать это в Java? Этот вопрос конкретно о разнице между C ++ и Java относительно этой техники.
я не интересно услышать личное мнение о том, является ли это вообще хорошим объектно-ориентированным дизайном, хотя я я интересно услышать, есть ли какие-либо культурные различия между C ++ и Java, которые могут заставить общее мнение склоняться так или иначе.
[РЕДАКТИРОВАТЬ]К сожалению, я не получил ответа на свой вопрос, мое редактирование, чтобы попытаться сделать его менее основанным на мнениях, не помешало его закрыть, поэтому я не могу выбрать приемлемый ответ. Можно было бы истолковать это как то, что на самом деле нет технической причины, по которой вы бы не хотели этого делать (предполагая, что это хорошая практика в C ++), и любое противодействие этому методу является чисто личным или культурным явлением Java.
Решение
WebBrowserStuff.clearBrowser(browser);
является статическим методом, который определен для класса и не имеет прямого доступа к экземпляру за пределами того, который передается. Это требует другой класс по служебным соображениям. Обычно в самих библиотеках Java это делается только тогда, когда мы работаем либо со специализированным типом, который не может справиться со всеми этими статическими методами (Array объекты, контрастирующие с утилитами в Arrays класс или Collectionsгде мы работаем с широким набором интерфейсов, которые не должны принимать статические методы.
Эти вспомогательные классы, как правило, не являются хорошей практикой, и в вашем случае вы можете, и должен, положил clearBrowser как нестатический метод WebBrowser,
Теперь, это было сделано, и хотя это не совсем хорошая практика, это технически обоснованно, и нет никаких договорных обязательств, лишающих вас этого права. На этой ноте, чтобы встретиться с именами библиотек Java, я бы назвал вспомогательный класс WebBrowsers поскольку библиотеки обычно берут рассматриваемый класс / интерфейс и плюрализуют его для этой цели именования.
Другие решения
Приемлемо, да. Предпочитается, нет. И вот почему: статические методы по своей природе исключаются из накладных расходов при создании экземпляров — поэтому довольно глупо создавать новый класс только для некоторых вспомогательных методов класса WebBrowser. Если что, добавьте статический метод в класс WebBrowser. Это позволяет избежать многословия, о котором вы говорили, и сохраняет все вместе. Тем не менее, я также согласен с Колином в том, что если вы создаете это как тип библиотеки или что-то, что позже будет расширено, то не стоит слишком скрывать вещи с самого начала.
Нет, это не распространено в Java, и это не способ сделать это.
Созданный вами WebBrowserStuff в Java выглядит как плохая реализация шаблона Singleton.
Одна проблема с вашей реализацией заключается в том, что вы можете создать несколько экземпляров WebBrowserStuff. Кажется, вам нужен только один, поэтому вы должны использовать одиночка.
Подумайте, хотите ли вы использовать эти методы в браузере. Кажется, это правильный путь в вашем случае. Они должны быть частью браузера.
Однако, если вы хотите создать вспомогательный класс, убедитесь, что вы сделали его Singleton: добавьте приватный конструктор, чтобы никто, кроме класса, не мог создать экземпляр и добавить метод getInstance () для его получения.