Есть гетер. Если используешь обьект возращаемый гетером несколько раз в примерно одном месте. Так вот как вернее постоянно дергать гетер или один раз запомнить обьект возвращаемый гетером? (Обьект в гетера однозначно не изменяется в данном месте).
Здравствуйте, MerZoD, Вы писали:
MZD>Есть гетер. Если используешь обьект возращаемый гетером несколько раз в примерно одном месте. Так вот как вернее постоянно дергать гетер или один раз запомнить обьект возвращаемый гетером? (Обьект в гетера однозначно не изменяется в данном месте).
Абстрактный какой-то вопрос, выдраный из контекста. Если "примерно одно место" ограничивается одним методом, то лично я всегда выношу объект в локальную переменную.
Здравствуйте, MerZoD, Вы писали:
MZD>Есть гетер. Если используешь обьект возращаемый гетером несколько раз в примерно одном месте. Так вот как вернее постоянно дергать гетер или один раз запомнить обьект возвращаемый гетером? (Обьект в гетера однозначно не изменяется в данном месте).
Если речь про легкий getter, то сохраняю объект в локальной переменной с модификатором final, если метод обращается к нему более 2-х раз, и речь здесь скорее идет только о стилистике-читаемости, а не о какой-то оптимизации.
Здравствуйте, MerZoD, Вы писали:
MZD>Есть гетер. Если используешь обьект возращаемый гетером несколько раз в примерно одном месте. Так вот как вернее постоянно дергать гетер или один раз запомнить обьект возвращаемый гетером? (Обьект в гетера однозначно не изменяется в данном месте).
А какая цель вообще преследуется? Если хочется оптимизировать код, т.е. извабить JVM от лишних вызовов метода, тогда не стоит этого делать. Вообще не стоит делать оптимизацию кода до того момента, пока это действительно не потребуется, особенно в ущерб читабельности.
Здравствуйте, BigInteger, Вы писали:
BI>А какая цель вообще преследуется? Если хочется оптимизировать код, т.е. извабить JVM от лишних вызовов метода, тогда не стоит этого делать. Вообще не стоит делать оптимизацию кода до того момента, пока это действительно не потребуется, особенно в ущерб читабельности.
Читаемость как раз страдает когда по 10 раз вызывается метод, чтобы достать объект, вместо одного раза и последующей работы с этим объектом через локальную переменную.
Здравствуйте, Blazkowicz, Вы писали:
B>Читаемость как раз страдает когда по 10 раз вызывается метод, чтобы достать объект, вместо одного раза и последующей работы с этим объектом через локальную переменную.
Причем в final-переменную.
BI>А какая цель вообще преследуется? Если хочется оптимизировать код, т.е. извабить JVM от лишних вызовов метода, тогда не стоит этого делать. Вообще не стоит делать оптимизацию кода до того момента, пока это действительно не потребуется, особенно в ущерб читабельности.
А мне кажется VM сделает этому геттеру inline и даже этих крошечных расходов на вызов метода не будет.
Здравствуйте, Blazkowicz, Вы писали:
B>Читаемость как раз страдает когда по 10 раз вызывается метод, чтобы достать объект, вместо одного раза и последующей работы с этим объектом через локальную переменную.
А вот здесь наоборот такую переменную inline-ят. У меня самого чёткого отношения нет, вроде и так и так читабельно.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, vsb, Вы писали:
vsb>>А вот здесь наоборот такую переменную inline-ят. У меня самого чёткого отношения нет, вроде и так и так читабельно. B>
B>You have a temp that is assigned to once with a simple expression
У вас есть временная переменная, которой один раз присваивается простое выражение. И что? У вас ведь это и есть.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Blazkowicz, Вы писали:
B>>Здравствуйте, vsb, Вы писали:
vsb>>>А вот здесь наоборот такую переменную inline-ят. У меня самого чёткого отношения нет, вроде и так и так читабельно. B>>
B>>You have a temp that is assigned to once with a simple expression
vsb>У вас есть временная переменная, которой один раз присваивается простое выражение. И что? У вас ведь это и есть.
К сожалению компилятор не так умен как вы думали:
return (new A()).getA();
Code:
0: new #2; //class A
3: dup
4: invokespecial #3; //Method A."<init>":()V
7: invokevirtual #4; //Method A.getA:()I
10: ireturn
а это для промежуточной final
Code:
0: new #2; //class A
3: dup
4: invokespecial #3; //Method A."<init>":()V
7: astore_1
8: aload_1
9: invokevirtual #4; //Method A.getA:()I
12: istore_2
13: iload_2
14: ireturn
Здравствуйте, Aib, Вы писали:
Aib>К сожалению компилятор не так умен как вы думали:
[байткод]
Насколько я знаю, компилятор, который переводит java код в байткод, почти не занимается оптимизацией(разве что заменяет конкатенации строк на StringBuffer.append()). в основном оптимизацию производит JIT.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, vsb, Вы писали:
vsb>У вас есть временная переменная, которой один раз присваивается простое выражение. И что? У вас ведь это и есть.
Нет. Когда переменная используется множество раз в одном методе, это немного другая ситуация.
Здравствуйте, vsb, Вы писали:
vsb>А вот здесь наоборот такую переменную inline-ят. У меня самого чёткого отношения нет, вроде и так и так читабельно.
Да это то случай простейший, здесь инлайнить имеет смысл. Я для себя выработал правило — всегда выносить переменную, если она используется в методе 2 или более раз. Не из целей оптимизации, а из целей читаемости — я документирую таким образом тип этой переменной и называю ее нормальным именем, символов становится меньше, читать проще. Когда используется она один раз часто не выношу, а пользуюсь просто геттером, но если надо обработать Null или еще что-то сделать с переменной, за выражения типа callMethod(processNull(getVar1(processNull(getVar2(processNull(getVar3()))))) готов убить. К сожалению студенты так очень любят писать, так как если сложно понимается — значит круто, да еще и строчек меньше . А иногда так пишут и опытные, которые привыкли к такому стилю, так как в свое время их не остановили — вот тогда вообще жесть .
