Я обычно обнаруживаю, что я извлекаю общее поведение из классов в классы helper/utility, которые не содержат ничего, кроме набора статических методов. Я часто задавался вопросом, следует ли объявлять эти классы абстрактными, так как я не могу думать о действительной причине когда-либо создавать их?
Какими бы "за" и "против" было объявить такой класс абстрактным.
public [abstract] class Utilities{
public static String getSomeData(){
return "someData";
}
public static void doSomethingToObject(Object arg0){
}
}
Вы можете просто объявить закрытый конструктор, который ничего не делает.
Проблема с объявлением класса "abstract" заключается в том, что ключевое слово abstract обычно означает, что класс предназначен для подкласса и расширения. Это определенно не то, что вы хотите здесь.
Не беспокойтесь, делая их абстрактными, но включите частный конструктор без параметров, чтобы предотвратить их создание.
Точка сравнения для заинтересованных: в С# вы должны объявить класс статическим, делая его абстрактным и запечатанным (окончательный Java) в скомпилированной форме и без какого-либо конструктора экземпляра вообще. Это также делает ошибку компиляции, чтобы объявить параметр, переменную, массив и т.д. Этого типа. Handy.
Я не объявляю абстрактные утилиты, я объявляю их окончательными и делаю конструктор закрытым. Таким образом, они не могут быть подклассами, и они не могут быть созданы.
public final class Utility
{
private Utility(){}
public static void doSomethingUseful()
{
...
}
}
Объявляя их абстрактными, вы на самом деле указываете другим кодам, для которых вы предназначались для этих классов. Действительно, вы правы, что нет большой разницы, но семантика здесь больше связана с интерпретацией других людей, которые смотрят на ваш код.
Я бы добавил еще один шаг за пределы частного конструктора:
public class Foo {
// non-instantiable class
private Foo() { throw new AssertionError(); }
}
Бросок AssertionError запрещает методам в том же классе создавать экземпляр класса (ну, они могут попробовать). Обычно это не проблема, но в командной среде вы никогда не знаете, что кто-то сделает.
Что касается "абстрактного" ключевого слова, я заметил, что классы утилит подклассифицированы в многочисленных случаях:
public class CoreUtils { ... }
public class WebUtils extends CoreUtils { ... }
public class Foo { ... WebUtils.someMethodInCoreUtils() ... }
Я считаю, что это сделано для того, чтобы люди не должны были помнить, какой класс утилиты включать. Есть ли недостатки в этом? Это анти-шаблон?
С уважением, LES
Как указывалось другими, создайте частный конструктор без параметров. Никто не может создать экземпляр этого объекта, кроме самого класса.
Как показали другие, как это делается с другими языками, вот как вы это делаете в следующей версии С++, как сделать класс неактивным:
struct Utility {
static void doSomething() { /* ... */ }
Utility() = delete;
};
Нет, но если ваш язык поддерживает его, есть веский аргумент, который следует сделать в большинстве случаев, когда они должны быть объявлены как "статические"... Static сообщает компилятору, что они не могут быть созданы, и что все методы в них должны быть статическими.
Реферат предназначен для классов, у которых есть детали реализации на основе экземпляра, которые будут использоваться экземплярами производных классов...
Вспомогательные методы просто хороши. Не беспокойтесь о добавлении их в библиотеку внутри вашего приложения или Framework. Большинство структур, которые я видел, используют их во многих вариантах.
Говоря об этом, если вы хотите получить хитрое из них, вы должны изучить методы расширения в С# 3.0. Использование метода расширения сделает ваши утилиты немного более "целостной" частью вашей структуры, которая кажется тем, что вы пытаетесь сделать, рассматривая их абстрактную. Не говоря уже о методе расширения, очень весело писать!
кто-то сказал, что в С# 3.0 вы можете выполнить это с помощью методов расширения. Я не парень из С#, немного вернулся в 1.5/2.0 дня, но не использовал его с тех пор. Основываясь на очень поверхностном понимании, я думаю, что нечто подобное может быть выполнено в java со статическим импортом. Я понимаю, что это совсем не то же самое, но если цель состоит в том, чтобы просто сделать эти методы утилиты кажутся немного более "родными" (из-за отсутствия лучшего термина) вызывающему классу, я думаю, что это будет трюк. Предположим, что класс Utilities, указанный в моем первоначальном вопросе, был объявлен.
import static Utilities.getSomeData;
public class Consumer {
public void doSomething(){
String data = getSomeData();
}
}
Могу ли я предложить конструктивный совет?
Если вы делаете много всего, есть две проблемы, с которыми вы столкнетесь.
Прежде всего, статический метод, который принимает параметр, часто должен быть частью объекта, являющегося этим параметром. Я понимаю, что это не помогает для таких объектов, как String, но если он принимает объекты, которые вы определили, вы почти наверняка улучшите объект, включив в него помощника как метод этого объекта.
Если он принимает все собственные значения, вы, вероятно, можете определить объект, которым он является метод. Посмотрите, можете ли вы найти группировку этих собственных значений и сгруппировать их в качестве объекта. Если вы просто попробуете это, вы найдете много других применений для этого маленького мини-объекта, и, прежде чем вы это узнаете, это будет удивительно полезно.
Другое дело, если у вас есть класс утилит с кучей полустационарных статических методов и статических переменных, вы почти всегда хотите, чтобы он был одиночным. Я обнаружил это методом проб и ошибок, но когда вы узнаете, что вам нужно больше 1 (в конце концов, вы это сделаете), намного проще сделать одноэлементный код в несколько раз (?), Чтобы попытаться изменить статический класс на несколько точек ( хорошо, поэтому я сейчас делаю слова).
Удачи. Этот материал был в основном пробным и ошибочным для меня - понял это, как и 5 лет назад, хотя, и я никогда не нашел экземпляр, где я сожалел о том, что у меня нет статического класса/методов.
Я думаю, что лучше объявить служебные классы final с помощью частного конструктора без аргументов. Более того, все члены этого класса должны быть статичными.
Простой способ сделать все это в одном утверждении - использовать аннотацию @UtilityClass для Lombok:
@UtilityClass
public class Utilities{
public String getSomeData() {
return "someData";
}
public void doSomethingToObject(Object arg0) {
}
}
Если вы используете аннотацию @UtilityClass, вы можете пропустить статические ключевые слова, как в примере выше, поскольку Lombok добавляет их автоматически во время компиляции.