Здравствуйте, avpavlov, Вы писали:
вопрос был не в этом! (понятно чтобы не было NPL лучше "abc".equalsIgnoreCase(...)
вопрос : надо использовать переменныю или вызовы методов
Здравствуйте, Аноним, Вы писали:
А>вопрос : надо использовать переменныю или вызовы методов
Смотреть надо не на эффективность. Вызов метода — это копипаст. Если выделишь переменную — она служит для документирования того, что там находится. В результате читать будет легче, ибо меньше символов на строке и меньше дубликатов.
Здравствуйте, Аноним, Вы писали:
А>вопрос : надо использовать переменныю или вызовы методов
В общем случае, вариант с переменной лучше. Его проще читать. Его проще дебажить. В случае NPE сразу понятно кто был null.
Но. Любые вызовы Domain Model вида obj.getProperty().getSubProperty(), это первый тревожный звонок по поводу нарушения инкапсуляции.
Скорее всего, вариант myClass.matchAbc("abс") был бы оптимальной альтернативой.
C>во втором случае getAbc вызовется два раза. но это не важно если getAbc простой геттер (потому что заинлайнится).
А как будет инлайниться такой "простой" геттер?
public class A {
private int b;
public int getB() {return b;}
}
public class B extends A {
public int getB() {return 0;}
}
public class X {
public boolean f(A a) {return 2 == a.getB() || 1 == a.getB();}
}
C>>во втором случае getAbc вызовется два раза. но это не важно если getAbc простой геттер (потому что заинлайнится).
A>А как будет инлайниться такой "простой" геттер?
C>а это не простой гетер, это метод имеющий перегрузки.
C>поясню: простой гетер — это метод возвращающий значение поля.
в классе A.getB() — это метод возвращающий значение поля. Про перегрузки в момент JIT-компиляции A.getB() или X.f() ничего неизвестно.
JIT, компилируя метод X.f(), может только быть уверен только для private или final методов/классов. Твоё утверждение безаппеляционно утверждало "но это не важно если getAbc простой геттер (потому что заинлайнится)."
Я просто намекнул тебе, что не бывает "простых геттеров", какими бы простыми они тебе не казались.
Здравствуйте, avpavlov, Вы писали:
A>в классе A.getB() — это метод возвращающий значение поля. Про перегрузки в момент JIT-компиляции A.getB() или X.f() ничего неизвестно.
A>JIT, компилируя метод X.f(), может только быть уверен только для private или final методов/классов. Твоё утверждение безаппеляционно утверждало "но это не важно если getAbc простой геттер (потому что заинлайнится)."
A>Я просто намекнул тебе, что не бывает "простых геттеров", какими бы простыми они тебе не казались.
он умнее чем ты думаешь. если никаких наследников класса A не загружено то в методе f все заинлайнится. как только будет загружен класс B скомпилированная версия f будет выброшена и перекомпилирована заново.
C>он умнее чем ты думаешь. если никаких наследников класса A не загружено то в методе f все заинлайнится. как только будет загружен класс B скомпилированная версия f будет выброшена и перекомпилирована заново.
Если будет загружена только одна реализация getAbc (при загрузке второго класса с другой реализацией getAbc будет выполнена деоптимизация) и getAbc будет заинлайнен (определяется профилем, собранным при запуске приложения, а так же зависит от размера метода, по умолчанию — 35 байт) то есть шанс, что после инлайнинга сработает common subexpression elimination, и переменная для хранения результата работы myClass.getAbc будет сгенерирована автоматически. CSE имеет больше шансов сработать, если в методе getAbc нет циклов, условий и побочных эффектов, например, присвоений значений полям объекта. Для простого геттера все условия, кроме первого, будут гарантированно выполнены. Первое же условие выполнится, если данный код вызывается часто, т.е. если вообще имеет смысл его оптимизировать.
