Сегодня всю ночь эта фигня снилась, пытался посчитать все возможные варианты...
Часто самопроизвольно стали получаться вот такие методы:
public class RussianMujik {
private String snils;
private String passport;
private String oms;
public static RussianMujik from(String snils, String passport, String oms) {
RussianMujik dto = new RussianMujik();
dto.snils = snils;
dto.passport = passport;
dto.oms = oms;
return dto;
}
}
По сути, оно выполняет ту же роль, что конструктор.
Хочется узнать, какие проблемы (или наоборот, фичи) в замене конструктора на такие методы?
Есть такие идеи: в конструкторе серверной жабе позволительно делать реордеринг, значит или мы не зовём из конструктора методы вообще, или должны заниматься маниакальнейшей safe publication с учетом всех сайд-эффектов. Иначе говоря, не можем мы звать из конструктора методы.
Причем если в конструкторе есть всякие volatile и final (они отключают реордеринги и другие оптимизации, т.к. чекпоинт, емнип), и нужно греть мозг про путь исполнения, чтобы повсеместное использование такого не стало дырой в перфомансе.
(Ну допустим, что мы будем выполнять это не только на x86_64, где оптимизаций 3,5 штуки, но еще и на всяких альфах, или что там умеет в них)
На обычные методы вроде всё это не распространяется, у нас есть уже полностью сконструированный валидный объект с точки зрения JVM.
Но ведь логически он как раз полностью НЕ сконструированный, то есть в будущем нужно будет наворотить поверх всяких синхронизаций?
(не про этот простой пример, конечно, а вообще, на вырост).
Слишком мало знаю про жвм, чтобы посчитать долгоиграющие последствия :(
Короче, напишите сюда своё имхо, плз. (А я пока наверну еще с десяток методов from xD)
=====================================================
UPD вспомнил еще один специальный случай, про который нужно имхо:
public static enum FIELDS {
snils, oms, passport;
}
public class RussianMujik {
private String snils;
private String passport;
private String oms;
public static RussianMujik from(ConcurrentHashMap data) {
RussianMujik dto = new RussianMujik();
dto.snils = data.get(FIELDS.snils);
dto.passport = data.get(FIELDS.passport);
dto.oms = data.get(FIELDS.oms);
return dto;
}
}
ВРОДЕ БЫ это отлично работает с синхронизацией с веб-интерфейсом с помощью сериализации (получаем JSON, конвертим в хэшмапу джексоном, посылаем в «неконструктор» как показано выше). Тут ясен огромный импакт от создания и навигации по мапе. И вообще, если веб-интерфейс, то все полимеры просраны на него, всё висит на IO и жрёт 50 гигабайтов рамы на стринги, байтоёбствовать уже не имеет смысла.
Очевидный профит тут в том, что можно простым образом зажилить в in-memory кэш параметры конструктора, и потом вместо клонирования объекта (а большинство объектов проще сделать повдоль, чем склонировать) просто конструировать их заново «неконструктором» с параметрами из кэша.
Неясен эффект на юзабилити подобных конструкций. Т.е. не окажется ли так, что через некоторое время все возненавидят такой способ (по неясной пока причине)
