Ответ 1

Я считаю, что разработчики использовали String в качестве замены (скорее всего, непреднамеренно) для перечисления, а static String[] - способ группировать эти типы.

Это может быть нацеливание на недостатки дизайна, которые были распространены на момент написания статьи

Для всех, кого мы знаем, эта статья может быть нацелена на базу Java-кода.

Не сказать, что это было написано во время Java 4, но тот самый производственный код, существующий в то время, возможно, был написан на Java 4. Отсутствие ловушек автобоксинга (которые довольно распространены) и никаких упоминаний о дженериках (сырых типах) мне поверить в это.

Почему Oracle применяет такой критический принцип?

Я не считаю, что это связано с глобальным состоянием, так как я уверен, что одноточие было бы упомянуто (являясь точкой глобального состояния).

Я сомневаюсь, что проблема с w390 связана с тем, что в статье ничего не говорится об обмене данными по потокам или даже при использовании нескольких потоков. Вы могли бы предположить, что они упомянули бы о ЧТО-ТО о среде потока.

Неправильное использование String для целей перечисления типов было общим в тот же день, поэтому я уверен, что это утверждение (если оно связано с тем, что я думаю) было намного легче понять тогда. Я нахожу, что это довольно растянуто, что это утверждение было столь же загадочным в то время, но никто не заботился о том, чтобы подвергнуть сомнению его, что привело к отсутствию результатов Google, когда они копались в этом.

Мой ответ

Разработчики по сей день все еще злоупотребляют String для информации о типе. Из-за отсутствия перечисления я мог видеть, как у разработчика может возникнуть соблазн сделать что-то в соответствии с:

class Card {
    static String HEARTS = "HEARTS";
    static String DIAMONDS = "DIAMONDS";
    static String CLUBS = "CLUBS";
    static String SPADES = "SPADES";

    static String[] CARD_TYPE = {
        HEARTS, DIAMONDS, CLUBS, SPADES
    };

    private String type;
    //...
}

Использование массива для легкого циклирования (как и с Enum.values()).

Используя String, поскольку перечисления неодобрились:

• Это не безопасный тип. Если MAGE можно передать методу, в нем может быть передано ANY String. Это приводит нас к...

• Ошибки легче сделать. Возможно, опечатка останется незамеченной, что может показаться маленьким для среднего разработчика, но может быть катастрофическим для предприятий с большими базами кода и многими потребителями (такими как Oracle). Например: скрытая опечатка приводит к тому, что сравнение возвращает false. Это предотвращает запуск службы. Отсутствие этой услуги приводит к ошибке. Если не обнаружено, прежде чем пользователи заметят ошибку, это может привести к эксплойтам.

Это может быть исправлено с помощью встроенной системы Java:

abstract class CardType {

}

class Hearts extends CardType {

}

....

или

enum CardType {   СЕРДЦА, АЛМАЗЫ,...; }

Мало того, что это менее подвержено ошибкам, но позволяет использовать полиморфизм, который предотвращает необходимость проверки значения, чтобы вызвать конкретное поведение. Поведение может содержаться в самом типе.

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

Да, в приведенном выше примере не используются правильные константы (отсутствует final). Но, хотя константы должны быть предпочтительнее, они не обязаны извлекать выгоду из этого проекта (имея возможность использовать String для информации типа), а также не требует, чтобы дизайн работал. Поскольку люди не всегда использовали константы для этого, они могли бы оставить для этого final или "массив констант".

Ответ 2

Массивы являются изменяемыми контейнерами. Глобальный универсальный контейнер без встроенной синхронизации - это многопоточный ужас, ожидающий своего существования. Вы можете хранить ссылку на этот массив в каком-то локальном контексте, а затем изменить его содержимое в любое время, не зная об этом. Или, наоборот, вы можете предположить, что это удобное глобальное состояние, но каждый клиент должен знать точно правильный способ синхронизации своего доступа к этому состоянию. И кто-то забудет, и появится ошибка.

Ответ 3

Таким образом, подрывается объектно-ориентированная парадигма. Кроме того, это дыра в безопасности, потому что final ключевое слово обеспечивает только эталонное значение и оставляет содержимое, чтобы быть легко изменен.

Ответ 4

Некоторые из них произвольны. Например, наличие одного оператора return - это вопрос стиля (возможно, связанный с некоторым инструментом анализа, который в прошлом не мог обрабатывать несколько путей возврата?).

Некоторые из них устарели. Как и в StringBuilding.

Я бы предположил, что это смесь старых рекомендаций по производительности и руководств по стилю. Я считаю, что статический массив String попадает в последнюю категорию, и может быть, намек на то, что другие говорили о возможной связи с введением перечислений (возможно, именно поэтому в частности Strings).

Некоторые из них на самом деле совершенно неосуществимы, когда вы пытаетесь применить их к современным фреймворкам: "Не используйте переключатель для совершения вызова на основе типа объекта", например, лежит в основе Akka Java (onReceive ) и вообще в любом типе сопоставления шаблонов в Java...

Хотя я признаю это любопытным, я бы сказал, что это, вероятно, что-то связанное с каким-то конкретным инструментом, который они использовали в прошлом, или упомянутой возможностью перечисления. Но это только мое мнение, а не окончательный ответ.