можно, конечно, посткомпиляцией обернуть все небезопасные обращения к переменным типа String.
Но NPE на строках, по-моему не такая уже большая проблема.

maytonВот это реально проблема. Лопатить весь код.

про "посткомпиляцию" ты зачем-то ловко из моего коментария выкинул. Конечно же не руками делать.

J.SergeКрасивый код из примера по ссылке:


Даа... фак мой мозг от JSF.

mayton


Инкапсуляция ни к черту. Это и есть та самая Anemic Model на которую так плюётся Фаулер. Почему всё это не находится внутри объектов someObject и subObject? Почему текущему классы приходится обращаться к Property ещё через две ссылки?
Некий внешний класс проводит манипуляции\проверки состояния каких-то объектов, вместо того чтобы делигировать им эту логику.

javapeckerBlazkowicz,
так работает мозг, сначала проверка someObject!=null, потом вспоминает что еще можно проверить, и руки сами дописывают остальное
Я бы не называл это "работает мозг". Это называется что вижу, то пою. NPE? Та, пофиг. Не будем фиксить первопричину. Просто добавим проверку на null.

maytonЯ полез в дебри. В нашем продакшен коде очень много паттернов типа




И строки это просто частный случай. Много операций использующих логику проверок и сравнения с null.

Кружусь в медленном вальсе. Медитирую. Пью кофе и грызу конфетки.
Поэтому я написал выше что строки это очень частный случай. Проблемы null значений он не решит.
Я стараюсь минимизировать проверки на null и, если возникает NPE, фиксить его в одном месте там где появляется null значение. А не во всех местах куда оно распространяется в итоге.
А так, рекомендации стандартные
NullObject pattern
@NotNull (Oval, IntelliJ IDEA и многие другие)
Языки с интегрированым NotNull, например Kotlin.

maytonЯ унаследовал этот код от предшественников. И задача вобщем-то не стоит как "Почему-бы не".

А как тогда задача стоит?

maytonПросто нет времени и возможности рефакторить фундамент. А начать сначала
с каких-то разумных упрощений по мере возможности - это да.

Не нужно рефакторить. Выкидываем проверку на null, где она не нужна. Добавляем NotNull для выявления источника null значения.
Исправляем на NullObject либо выкидываем Exception\делаем валидацию на месте появляения null, а не на месте использования.

maytonА появление null-аргументов String растёт корнями из ORM, DAO и прочих слоёв которые
сопрягаются с БД. Что поделаешь. NULL для БД - это нормально.
Нет, это не нормально. Во-первых NULL поля в базе тоже стоит свести к минимуму и оставить только там где они действительно нужны.
Во-вторых проверки на null значения свойств сущностей зачастую легко инкапсулируются в самих сущностях, и тогда весь остальной код можно от них избавить. Без конкретного примера понять не просто. Покажи реальный похожий код из системы и объясни источник null значений. Тогда можно обсудить как выкинуть лишние проверки.

maytonЯ место появления знаю. 99% это объекты DAO. Переходники MyBatis.
Замечательно. Тогда просто нужно отказываться от абсолютно анемичных сущностей и выносить эти провери туда. Код станет намного проще.

scymaks,

Отчасти. В данном случае DAO является пользователем значения, а не источником. К анемике это имеет мало отношения. Здесь мы просто валидируем входной аргумент, сродни assert-ам, патаясь сделать защиту от нерадивых коллег. Но по хорошему, да. В указаном месте бороться с null значнием уже поздно. По хорошему, ведь, нужно исправить код, который передаёт методу save null значение.