Почему toBinaryString не является методом экземпляра в классе Integer?

простой вопрос дизайна.

пример кода:

    Integer int1 = new Integer(20);     
    System.out.println(Integer.toBinaryString(int1));

почему дизайн JDK не похож на следующее? Итак, функция toBinaryString возвращает желаемый результат?

    System.out.println(int1.toBinaryString());

в сторону для широкого использования статической функции, какие другие причины для этого подхода к проектированию? Они используют какой-то определенный шаблон дизайна? Если это так, то какой шаблон?

10
design design-patterns java

4 ответов

ваш пример кода создает экземпляр Integer и потом unboxes его. В этом нет необходимости:

int int1 = 20;
String binary = Integer.toBinaryString(int1);

если бы это был метод экземпляра, вы были бы заставили создать экземпляр Integer исключительно для того, чтобы преобразовать int к его двоичному представлению, которое было бы раздражающим.

другими словами: чтобы избежать создания объектов без необходимости.

9

это потому, что вы не можете иметь два метода с одинаковым именем, один статический и один экземпляр. Наличие двух разных имен методов для одной и той же функциональности снова было бы запутанным.

ввод статического метода казался более логичным, так как в этом случае вам не пришлось бы "обертывать" int в целое число, прежде чем получить его двоичное представление, и он служит обеим целям (двоичная строка для int и Integer).

15

назад, когда этот метод был добавлен, в JDK1.0.2, не было автобоксинга, и JVMs были намного медленнее, чем сейчас. Я полагаю, что наличие этого статического метода позволило легко преобразовать как int, так и целое число в двоичную строку и без необходимости создавать новый экземпляр Integer только для преобразования int в двоичный.

6

int, char, double ... это тип данных по умолчанию, это не объект. Метод должен быть частью объекта, а не тип данных.

такой статический метод более эффективен, чем метод экземпляра.

0