Статьи

Последнее слово на «финале»

Сентябрь 26, 2018

В Java чрезмерное использование final похоже на крик. Это устарело и неуместно в большинстве случаев.

Java и JavaScript

В основном это final ключевое слово в Java, но мое мнение о его аналоге const в JavaScript немного изменилось. То, что я могу думать, что const — хорошая вещь, а final — плохая, требует распаковки.

Мне нравится const в JavaScript, потому что в целом код, использующий let или var обычно делает то, с чем я не согласен. В целом, переменная не должна переназначаться после того, как ей впервые присвоено значение. Это не верно для аккумуляторов или определенных циклических ситуаций, но это более верно, чем нет.

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

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

Давайте обеспечим это тогда?

Почему мы не должны применять его в Java?

В Java уже есть концепция эффективно final, которая приносит преимущества final конструкциям, которым нужно доверять чему-либо, является final — то есть лямбда-функциям и анонимным внутренним классам. По сути, компилятор уже знает, что является финальным, и для меня добавление final сверху похоже на крик. Это, безусловно, делает код более загруженным… чем меньше, тем больше, а final кажется переполненным.

Я прощу const в JavaScript, отчасти потому, что linter так сильно хочет вывести const а затем требовать его, а отчасти потому, что JavaScript — такой свободный язык, что нельзя доверять чему-либо, не выражая его твердо. Тем не менее, я бы предпочел не нужно!

Как мы можем доверять себе?

Да, но откуда мне знать, что что-то действительно final если я не говорю, что оно окончательно. Что если кто-то изменит это?

Пример А:

1
2
3
4
5
6
7
8
public bool isFound(List<String> list, String value) {
    for (final String item:list) {
        if (value.equals(item)) {
            return true;
        }
    }
    return false;
}

Приведенный выше код гарантирует, что item внутри цикла не может быть переопределен. Номер 1 — Кого заботит !? Номер 2 — метод очень короткий. Если придет ниндзя и попытается изменить значение item вы заметите это с помощью коротких функций.

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

Пример Б:

1
2
3
4
5
final boolean hadValue = isFound(myList, "Foo");
final boolean hadOtherValue = isFound(myList, "Bar");
final boolean bothFound = hadValue && hadOtherValue;
final String message = "They were both " + bothFound ? "found" : " not found";
return message;

Yawn!

1
2
boolean bothFound = isFound(myList, "Foo") && isFound(myList, "Bar");
return "They were both " + bothFound ? "found" : " not found";

Не заставляй меня следовать твоим мыслительным процессам слово за разом, а final — это приправа, приправленная текстом. Составляйте предложения из своего кода, которые объясняют все мысли и добавляют переменные и модификаторы, только если это необходимо.

Где финал приходит?

Я использую final разумно. Я должен сказать, что я делаю все дочерние сервисы моих компонентов / сервисов bean в Spring private final в моих классах, но я этого не делаю. Для этого есть аргумент, а именно то, что проводка сервисов внутри контекста приложения изначально неизменна, но я не склонен к этому. Если бы ты это сделал, я бы не стал спорить.

У меня есть два ключевых варианта использования, где final ОБЯЗАТЕЛЬНО!

Они оба о важности крика и неизменности.

Таким образом, вы всегда найдете меня использующим private static final SomeType SOME_CONSTANT_IN_CAPITALS в константах уровня класса, используемых в классе или в качестве глобальных переменных, потому что они особые и ДОЛЖНЫ рассматриваться как константы с дополнительной защитой — соглашение строго и опасность плохое обращение намного выше, чем локальная переменная в одной функции.

Вы обнаружите, что я хочу, чтобы неизменный шаблон был реализован правильно.

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

Но если вы хотите по-настоящему неизменных предметов для какой-то высокой причины, тогда я приветствую вас.

Вывод

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

Я перенесу ваш регистратор и ваши справочные данные в static final BLOCK_CAPITAL_NAME d вещи каждый день недели.

Но самое главное: заменить ВСЕ «финальные» на «» — это все еще один из самых приятных рефакторингов, которые я когда-либо делал.

Смотрите оригинальную статью здесь: последнее слово на «финале»

Мнения, высказанные участниками Java Code Geeks, являются их собственными.

36
Share: