Обязателен ли final в аргументах методов? - Java

Здравствуйте, Аноним, Вы писали:

А>Вот, дожил до седых волос и не знаю, нарвался тут на обсуждение http://community.livejournal.com/ru_java/772967.html?thread=9593447#t9593447 но так и не понял, обязательно ли подсказывать javac что агрумент в методе не изменится или компилятор никаких выводов из этого не сделает, не сможет использовать эту информацию для оптимизации?

комменты жгут:

За это final MyObject myObject = ...; сообщает одну важную вещь - значение больше не изменится

если класс final — нельзя его наследовать (пример java.lang.String), если метод final — его нельзя override, если свойство или переменная final — нельзя поменять его значение (для примитивов) / изменить ссылку (для объектов).

использование final для переменных удобно, дабы не наступать грабли, когда может измениться формальный параметр метода

HDB>если класс final — нельзя его наследовать (пример java.lang.String), если метод final — его нельзя override, если свойство или переменная final — нельзя поменять его значение (для примитивов) / изменить ссылку (для объектов).
тьфу блин — для объектов конечно же указатель.

HDB>использование final для переменных удобно, дабы не наступать грабли, когда может измениться формальный параметр метода
кстати, то, что это только проверка для этапа компиляции (защитить самого себя) можно проверить посмотрев байт-код — переменные и формальные параметры не имеют никаких доп. модификаторов

Здравствуйте, http://dolzhenko.blogspot.com/, Вы писали:

HDB>если класс final — нельзя его наследовать (пример java.lang.String), если метод final — его нельзя override, если свойство или переменная final — нельзя поменять его значение (для примитивов) / изменить ссылку (для объектов).
HDB>использование final для переменных удобно, дабы не наступать грабли, когда может измениться формальный параметр метода
Также final играет роль в безопасности инициализации: Теория и практика Java: Исправление модели памяти Java, часть 2. Как изменилась модель памяти Java в результате деятельности JSR 133?, мифах производительности и документировании: Теория и практика Java : Это ваш окончательный ответ? Руководство по эффективному использованию ключевого слова final.

Здравствуйте, http://dolzhenko.blogspot.com/, Вы писали:

HDB>>если класс final — нельзя его наследовать (пример java.lang.String), если метод final — его нельзя override, если свойство или переменная final — нельзя поменять его значение (для примитивов) / изменить ссылку (для объектов).
HDB>тьфу блин — для объектов конечно же указатель.

Таки всетаки ссылка.
Указатель это целое чисто содержащее в себе в качестве значения адрес памяти. В java такого нет.

Здравствуйте, Nicht, Вы писали:

N>Здравствуйте, http://dolzhenko.blogspot.com/, Вы писали:

HDB>>>если класс final — нельзя его наследовать (пример java.lang.String), если метод final — его нельзя override, если свойство или переменная final — нельзя поменять его значение (для примитивов) / изменить ссылку (для объектов).
HDB>>тьфу блин — для объектов конечно же указатель.

N>Таки всетаки ссылка.
N>Указатель это целое чисто содержащее в себе в качестве значения адрес памяти. В java такого нет.

таки всё таки указатель
JLS, 4.3.1 Objects:

The reference values (often just references) are pointers to these objects, and a special null reference, which refers to no object.

Здравствуйте, Аноним.

Если говорить именно об использовании модификатора final с аргументами методов, то единственное, что сразу приходит на ум, это возможность использования этих аргументов в method-local внутренних классах.

надо не забывать о том, что внутренний класс, объявленный в методе, может использовать только те аргументы метода и локальные переменные, которые объявлены с модификатором final

Цитата взята отсюда. Там же примеры.

Думаю, если нет особого смысла (требования) в использовании модификатора final для аргументов методов, не нужно париться. Компилятор сам, что нужно, оптимизирует. Java не для того создавалась, чтобы разработчики ломали голову над проблемой оптимизации.

Здравствуйте, msqrt84, Вы писали:

M>Думаю, если нет особого смысла (требования) в использовании модификатора final для аргументов методов, не нужно париться.

Это хорошо, теперь я буду это знать. Цель ветки и была в том, чтобы выяснить, т.к. байткод я читать не умею.

>Компилятор сам, что нужно, оптимизирует. Java не для того создавалась, чтобы разработчики ломали голову над проблемой оптимизации.

Ну, не скажи. Зачем тогда читать Thinking in Java? Зачем тогда даже писать такие книжки? Выучить синтаксис жабы (тем более что он достаточно простой) и вперед, городить ахинею, а если будет где-то тормозить, то это JVM виновата, нам же думать не нужно. Как раз нет, знать узкие места и избегать их а также учитывать best practices это и есть то, что позволяет использовать CPU эффективно, а ваять очередную тормозилку

Здравствуйте, Аноним.

Вообще говоря с Вами можно согласиться, но это вообще говоря. Есть много но ...
1. Когда программировал на pascal приходилось читать obj-файлы. И то в исследовательских целях. С ассемблером понятно: машинный код. Что касается Java ... ну не знаю, за 3 года не приходилось решать задачи, в которых нужно умение читать Java байт-код.
2. Что касается "Thinking in Java" эта тема для обсуждения мне нравиться.

Не раз дискутировали уже. Я начинал было читать эту книжку в студенческие годы, но мне она показалась чересчур "пухлой" что ли. Забросил. UML я изучал до знакомства с Java. Java ООП в рамках подготовки к сертификации по SCJA и SCJP. Есть очень много различных руководств кратких и более информативных. Что касается практик: "Эффективное программирование на Java" Джошуа Блоха мне вполне хватило. В итоге недавно снова кинул взгляд на Эккеля и понял, что ничего особенного, что повысило бы мою квалификацию, в нём нет. Работал в одном крупном российском интеграторе. Там были умы, которые использовали для отображения данных компонент, выгружающий на клиент (браузер) из базы все записи (например несколько тысяч). Только после этого можно было выполнить сортировку, например. Тормозило страшно, просто катастрофически. Счёт шёл на минуты. Там были и очень грамотные разработчики, читавшие Эккеля. Почему так? Да потому что процесс разработки не был поставлен. Достаточно ввести функциональное и нагрузочное тестирование, чтобы конечное решение было качественным.
5. Да, во многом JVM виновата. Не даром при переходе с 1.4 на 5.0 виртуальная машина была серьёзно оптимизирована, насколько я знаю.
6. Как можно упоминать об эффективном использовании CPU при упоминании Java! По тактам что ли расписывать! Если у Вас возникает такая задача, то использовать нужно явно не Java. Тогда уж написать dll на С/C++ с использованием JNI. Кстати, в качестве одного из преимуществ log4j приводится количество необходимых тактов для логирования. При этом неправильное использование log4j (да и другого API для логирования) на продакшене может привести к краху сервера. Делается это банальными настройками.
7. Цитата "Выучить синтаксис жабы ... ". Какой-то негативный оттенок. Такое чувство, что есть серьёзный опыт, но вот опыт с Java небольшой. Как-то вы всё усложняете. Это моё субъективное мнение.

P.S. Эккель вне конкуренции! Пишу, чтобы флэйма не было.

Здравствуйте, Аноним, Вы писали:

А>Это хорошо, теперь я буду это знать. Цель ветки и была в том, чтобы выяснить, т.к. байткод я читать не умею.
рекомендую открыть для себя декомлиряторы типа jad'а или какой лучше на вкус, а также обычный просмотр class-файла, reflection и jni

>>Компилятор сам, что нужно, оптимизирует. Java не для того создавалась, чтобы разработчики ломали голову над проблемой оптимизации.

А>Ну, не скажи. Зачем тогда читать Thinking in Java? Зачем тогда даже писать такие книжки? Выучить синтаксис жабы (тем более что он достаточно простой) и вперед, городить ахинею, а если будет где-то тормозить, то это JVM виновата, нам же думать не нужно. Как раз нет, знать узкие места и избегать их а также учитывать best practices это и есть то, что позволяет использовать CPU эффективно, а ваять очередную тормозилку

возможно, комрад msqrt84 слишком вольно выразился, имея в виду, что использование final для оптимизации кода очевидной разницы не даёт — не удивлюсь, если она и есть, но это уже vendor dependent, как и множество других внутри-java'вских оптимизационных фишек, как то jit

msqrt84 wrote:

> Если говорить именно об использовании модификатора final с аргументами
> методов, то единственное, что сразу приходит на ум, это возможность
> использования этих аргументов в method-local внутренних классах.
Мне кажется проставлять final у всех переменных, которые не меняются — просто правило хорошего тона. И вообще, использовать final везде, где только можно — даёт более чистый и прозрачный стиль, смахивающий на функциональный.

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

Posted via RSDN NNTP Server 2.1 beta

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

Если же под человеком Вы имеете ввиду клиента, то будьте добры пример конкретного кода, в котором необязательное использование модификатора final привело к заметной для клиента оптимизации (например, выигрыш в скорости обработки массивов данных или что-то типа того)?

Не думаю, что такой пример у Вас есть.

msqrt84 wrote:

> Если под человеком имеется ввиду другой программист, то думаю, Вы не
И сам программист спустя пару месяцев тоже.

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

> Если же под человеком Вы имеете ввиду клиента, то будьте добры пример
> конкретного кода, в котором *необязательное* использование модификатора
> final привело к заметной для клиента оптимизации (например, выигрыш в
> скорости обработки массивов данных или что-то типа того)? Не думаю, что
> такой пример у Вас есть.
Я не понял какую скорость ты имеешь в виду. Скорость написания кода и выдачи первой версии продукта клиенту или скорость выполнения программы?

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, ..

Вся эта подветка основывается на одном Вашем утверждении:

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

Учитывая, что Вы не пояснили, кого же Вы имеете ввиду под человеком, я сделал свой комментарий в 2-х возможных случаях. Вы так и не пояснили, кого же имеете ввиду, вместо этого начинаете заниматься демагогией про то, кто и что поймёт, пустые разговоры про рынок и т.д. Не хотите пояснять, не надо. Не надо вести пустые разговоры. Если делаете комментарий, то следите хотя бы за нитью разговора.

Везде где можно ставить модификатор final, это всё равно что постоянно добавлять в разговоре слово "положительное" к числам 1, 2, 3, ... Как адекватный человек понимает, что речь идёт о положительных числах, также и опытный разработчик понимает, что значит наличие/отсутствие модификатора final. Если у Вас это ещё не дошло до автоматизма, это просто напросто означает Ваш недостаточный опыт в Java.

Если Вы не понимаете, что за скорость имелась ввиду, прочитайте ещё раз тот абзац, к которому Вами бы сделан комментарий. Такое ощущение, что сделали комментарий к абзацу, который даже не прочитали.

msqrt84 wrote:

> Учитывая, что Вы не пояснили, кого же Вы имеете ввиду под человеком, я
> сделал свой комментарий в 2-х возможных случаях. Вы так и не пояснили,
> кого же имеете ввиду, вместо этого начинаете заниматься демагогией про
Я ответил "[Да.] И сам программист спустя пару месяцев тоже.".
Неужели так непонятно?

> то, кто и что поймёт, пустые разговоры про рынок и т.д. Не хотите
> пояснять, не надо. Не надо вести пустые разговоры. Если делаете
> комментарий, то следите хотя бы за нитью разговора.
"Пусть первый бросит в меня камень"

> Везде где можно ставить модификатор final, это всё равно что постоянно
> добавлять в разговоре слово "положительное" к числам 1, 2, 3, ... Как
Плохой пример. Тогда уж стоит вспомнить о разнице между 1 и 1.0. Скажем два выражения
x = y / 2;
a = b / 2.0;
могут иметь очень разный смысл.

> адекватный человек понимает, что речь идёт о положительных числах, также
> и опытный разработчик понимает, что значит наличие/отсутствие
> модификатора final. Если у Вас это ещё не дошло до автоматизма, это
> просто напросто означает Ваш недостаточный опыт в Java.
Скорее это ко мне пришло из C++ с его const.
Есть ли какие-то веские причины не писать final, кроме как экономить 6 символов?

> Если Вы не понимаете, что за скорость имелась ввиду, прочитайте ещё раз
> тот абзац, к которому Вами бы сделан комментарий. Такое ощущение, что
> сделали комментарий к абзацу, который даже не прочитали.
"впихнуть что-то работающее клиенту" мною однозначно понимается как "побыстрее налабать, дабы хоть как-то заработало". А "скорости обработки массивов данных" однозначно понимается скорость исполнения программы.
Так что выражение мыслей в твоём посте тоже не кристально чисто.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, ., Вы писали:

.>Мне кажется проставлять final у всех переменных, которые не меняются — просто правило хорошего тона. И вообще, использовать final везде, где только можно — даёт более чистый и прозрачный стиль, смахивающий на функциональный.

Абсолютно верно. Также даст хорошую защиту от дурака, покажет хороший тон и даст бОльшую наглядность, например, написание в каждом методе инвариантов на входные параметры — проверка необходимых аргментов на null в public methods и на валидность с точки зрения бизнес-логики (в т.ч. getters/setters) (случай с проверкой на null решается аннотациями @NotNull, но в общем случае надо делать проверку явно), вставка assert в private methods. Также будет более понятно назначение кода, если использовать this. для обращения к instance members. Еще можно упомянуть случай вызова метода, объявляющего checked exceptions во throws clause — по-хорошему, надо либо явно писать catch на каждый отдельный эксепшн (даже если все они будут делать в данный момент одно и то же), либо явно указывать в сигнатуре вызывающего метода эти же эксепшны (никаких 'catch (IOException)' с единым обработчиком или 'throws IOException' в случае вызова метода с 'throws FileNotFoundException, RemoteException' быть не должно). Еще хорошо бы писать юнит-тесты для каждого класса, потому как они клево автоматически проверяют, что ничего не поломалось...

Список того, что хорошо бы делать можно продолжать долго. Причем полезность каждого из пунктов можно отлично аргументировать как минимум используя доводы, приводившиеся в этом топике. Что я хотел сказать всем этим — времени сделать все, что было бы полезным для данного продукта, не хватит никогда. Поэтому надо идти на компромисс, т.е. расставлять приоритеты и делать не все, а только самое (субъективно) важное. Одни из моих основных приоритетов — быстрое написание программ и их легкая поддержка. Честно говоря не знаю, какие возможности предоставляют ide для автоматической вставки 'final' в объявления аргументов методов, но интересоваться даже не буду. Причина — чем больше в коде буковок, тем мне тяжелее его читать (снижается способность кода к поддержке).

.>А в контексте того, как оно оптимизируется оптимизатором — вообще не стоит думать, программа в первую очередь пишется для человека, а лишь потом нужно вспоминать всякие оптимизаторы.
Главное не забывать, что в первую очередь для человека, который платит за программу деньги

P.S. я и в объявлении методов интерфейсов не пишу модификаторы 'public abstract' у методов и 'public static final' у полей.

Здравствуйте, rsn81, Вы писали:

R>На самом деле это не правило хорошего тона: все правила хорошего тона должны быть в компиляторе, все же остальное от лукавого — здесь мы имеем дело с обезьяньим трудом в ограниченных условиях. Во-первых, у меня это (автоматическую пометку immutable) делает Eclipse IDE автоматически, за что ей большое спасибо. Во-вторых, при этом изобилие модификаторов final настолько велико, что встает вопрос. А зачем отмечать неизменность сущности, когда более лаконично было бы отмечать изменяемость, то есть почему бы не сделать все неизменяемым по умолчанию (не надо будет изобретать глупые правила хорошего тона по трудолюбивому расставлении везде-везде final), а вот когда нужна изменяемость, ставишь модификатор mutalbe?
Поискал, смотрю: эту мысль я, как старый пердун, уже как минимум 5 раз повторяю — все, на пенсию.

final-классы/методы вцелом зло, final-поля/переменные — добр
Re[2]: final keyword
Re[4]: final keyword
Re: Immutable data structures are the way of the future in C

Здравствуйте, rsn81, Вы писали:

R>Здравствуйте, ., Вы писали:

R>. А зачем отмечать неизменность сущности, когда более лаконично было бы отмечать изменяемость, то есть почему бы не сделать все неизменяемым по умолчанию (не надо будет изобретать глупые правила хорошего тона по трудолюбивому расставлении везде-везде final), а вот когда нужна изменяемость, ставишь модификатор mutalbe?
А можно как в Скале — val для немутабельных и var для изменяемых.

<< RSDN@Home 1.2.0 alpha 4 rev. 1128>>
Сейчас играет Track 11

Здравствуйте, Gajdalager, Вы писали:

G>Здравствуйте, rsn81, Вы писали:

R>>Здравствуйте, ., Вы писали:

R>>. А зачем отмечать неизменность сущности, когда более лаконично было бы отмечать изменяемость, то есть почему бы не сделать все неизменяемым по умолчанию (не надо будет изобретать глупые правила хорошего тона по трудолюбивому расставлении везде-везде final), а вот когда нужна изменяемость, ставишь модификатор mutalbe?
G>А можно как в Скале — val для немутабельных и var для изменяемых.
или const, которые любят совать всюду и везде, да mutable в C++ ... не спасибо, лучше уж final

Здравствуйте, ..

.>Я ответил "[Да.] И сам программист спустя пару месяцев тоже.".
.>Неужели так непонятно?

Если Вы цитируете самого себя, то не надо себе приписывать то, чего не писали. Ответа "Да" в Вашем оригинальном сообщении не было и лично мне такой ответ не был очевиден.

.>"Пусть первый бросит в меня камень"

Вы не посланник божий. Не льстите себе. А вообще, говорят, в Москве кур доят.

>> Везде где можно ставить модификатор final, это всё равно что постоянно
>> добавлять в разговоре слово "положительное" к числам 1, 2, 3, ... Как
.>Плохой пример. Тогда уж стоит вспомнить о разнице между 1 и 1.0. Скажем два выражения
.>x = y / 2;
.>a = b / 2.0;
.>могут иметь очень разный смысл.

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

.>Есть ли какие-то веские причины не писать final, кроме как экономить 6 символов?

Умножьте на N, где N — число методов, аргументов, переменных и т.д. (все считать не надо, догадайтесь, почему

). Мой и не только опыт показывает, что final намного легче не писать, чем писать. Не знаю людей, которых смущало бы отсутствие необязательного модификатора final.

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

Моя мысль выражена абсолютно чётко. Ещё раз специально для Вас цитата из моего сообщения:

Если же под человеком Вы имеете ввиду клиента, то будьте добры пример конкретного кода, в котором необязательное использование модификатора final привело к заметной для клиента оптимизации (например, выигрыш в скорости обработки массивов данных или что-то типа того)? Не думаю, что такой пример у Вас есть.

Надеюсь, что после выделения жирным Вам стало понятнее.

Советовал Вам не разводить демагогию. Чувствую, Вы меня в эту демагогию засасываете.

Есть один ориентир. И для меня. И для Вас. И для многих других. Этот ориентир — исходные коды Java классов. Откройте любой. Вы увидите, что даже для констант (видно по вызовам) где-то стоит final, а где-то нет. Дело вкуса, дело скорости разработки, дело в степени педантизма. Тема закрыта.

to ".": если снова решитесь делать комментарии, просьба читать сообщения внимательней и не приписывать себе того, чего не писали. Чувствую с Вами общаться, что биться головой об стенку. Вы просто не умеете воспринимать информацию, которую доводят до Вас другие. С таким часто приходиться встречаться, к сожалению.

Здравствуйте, rsn81, Вы писали:

R>Здравствуйте, rsn81, Вы писали:

R>>На самом деле это не правило хорошего тона: все правила хорошего тона должны быть в компиляторе, все же остальное от лукавого — здесь мы имеем дело с обезьяньим трудом в ограниченных условиях. Во-первых, у меня это (автоматическую пометку immutable) делает Eclipse IDE автоматически, за что ей большое спасибо. Во-вторых, при этом изобилие модификаторов final настолько велико, что встает вопрос. А зачем отмечать неизменность сущности, когда более лаконично было бы отмечать изменяемость, то есть почему бы не сделать все неизменяемым по умолчанию (не надо будет изобретать глупые правила хорошего тона по трудолюбивому расставлении везде-везде final), а вот когда нужна изменяемость, ставишь модификатор mutalbe?

Спасибо, про final я понял. Все-таки, плохо то что нет более-менее цельного ресурса, посвященного разработке для платформы Java, вот и про final я наткнулся на обсуждение в http://community.livejournal.com/ru_java, при этом однозначного ответа там не нашел, и пришел спрашивать сюда. Книжки типа ThiJ плохи тем, что пока дочитаешь до 20 главы, забываешь о чем писалось в 3-й, а время "вдумчиво читать и прорешивать все примеры" было только 20 лет назад в институте, счас просто нет на это времени

Вот теперь у меня про immutable structures вопрос. http://gzip.rsdn.ru/Forum/Message.aspx?mid=2684929&only=1 я скачал и почитаю на досуге, однако что такое эти immutable structures&variables? Вот к примеру банальный пример String a += somestring, работающий в цикле. Встречается в большой массе программ. Ну ладно, String не подходит, по-умолчанию immutable, ну тогда возьмем List. Эта коллекция тоже ведь должна быть immutable? Т.е. при измении ссылки в середине List на другую весь List нужно переносить в новую область памяти, с изменившейся ссылкой в середине? И так каждый раз? Ведь это жуть как неэффективно. Или я опять что-то неправильно понимаю?

Здравствуйте, Аноним.

А>Спасибо, про final я понял. Все-таки, плохо то что нет более-менее цельного ресурса, посвященного разработке для платформы Java, вот и про final я наткнулся на обсуждение в http://community.livejournal.com/ru_java, при этом однозначного ответа там не нашел, и пришел спрашивать сюда. Книжки типа ThiJ плохи тем, что пока дочитаешь до 20 главы, забываешь о чем писалось в 3-й, а время "вдумчиво читать и прорешивать все примеры" было только 20 лет назад в институте, счас просто нет на это времени

Ну как это нет цельного ресурса! А это. Даже на русском есть.

А>Вот теперь у меня про immutable structures вопрос. http://gzip.rsdn.ru/Forum/Message.aspx?mid=2684929&only=1 я скачал и почитаю на досуге, однако что такое эти immutable structures&variables? Вот к примеру банальный пример String a += somestring, работающий в цикле. Встречается в большой массе программ. Ну ладно, String не подходит, по-умолчанию immutable, ну тогда возьмем List. Эта коллекция тоже ведь должна быть immutable? Т.е. при измении ссылки в середине List на другую весь List нужно переносить в новую область памяти, с изменившейся ссылкой в середине? И так каждый раз? Ведь это жуть как неэффективно. Или я опять что-то неправильно понимаю?

1. "банальный пример String a += somestring, работающий в цикле" — никогда так не делайте. Сжираете память: при каждой конкатенации создаётся новый объект с соответствующим выделением памяти под строку. Для таких целей нужно использовать StringBuffer/StringBuilder (они mutable). Про строки тут хорошо написано.
2. У нас в памяти не List с объектами, а объекты, ссылки на которые хранятся в List. При какой-либо операции с List ссылка на объект поменялась и всё. Хотя надо не забывать, что List — это интерфейс. Реализаций масса. Где-то итерация происходит быстрее, где-то операции добавления/удаления элементов, сортировка и т.д. Коллекции — это, вообще, отдельная тема для обсуждения. Это целый фреймворк со своими тонкостями. Тут на пальцах не объяснить, надо читать. Вот просто брать главу из книжки и читать. По-другому никак. Про коллекции тут.

Здравствуйте, <Аноним>, Вы писали:

А>Спасибо, про final я понял. Все-таки, плохо то что нет более-менее цельного ресурса, посвященного разработке для платформы Java, вот и про final я наткнулся на обсуждение в http://community.livejournal.com/ru_java, при этом однозначного ответа там не нашел, и пришел спрашивать сюда. Книжки типа ThiJ плохи тем, что пока дочитаешь до 20 главы, забываешь о чем писалось в 3-й, а время "вдумчиво читать и прорешивать все примеры" было только 20 лет назад в институте, счас просто нет на это времени
Максимум черпаю на developerWorks. Ресурсы IBM для разработчиков и IT-профессионалов.

А>Вот теперь у меня про immutable structures вопрос. http://gzip.rsdn.ru/Forum/Message.aspx?mid=2684929&only=1 я скачал и почитаю на досуге, однако что такое эти immutable structures&variables? Вот к примеру банальный пример String a += somestring, работающий в цикле. Встречается в большой массе программ. Ну ладно, String не подходит, по-умолчанию immutable, ну тогда возьмем List. Эта коллекция тоже ведь должна быть immutable? Т.е. при измении ссылки в середине List на другую весь List нужно переносить в новую область памяти, с изменившейся ссылкой в середине? И так каждый раз? Ведь это жуть как неэффективно. Или я опять что-то неправильно понимаю?
Не неправильно, просто на айсберге видите только его верхушку. Читайте: Теория и практика Java: Изменять или не изменять? Неизменяемые объекты могут значительно облегчить вашу жизнь.

Здравствуйте, denis.zhdanov, Вы писали:

DZ>Одни из моих основных приоритетов — быстрое написание программ и их легкая поддержка. Честно говоря не знаю, какие возможности предоставляют ide для автоматической вставки 'final' в объявления аргументов методов, но интересоваться даже не буду. Причина — чем больше в коде буковок, тем мне тяжелее его читать (снижается способность кода к поддержке).

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

Здравствуйте, denis.zhdanov, Вы писали:

DZ>P.S. я и в объявлении методов интерфейсов не пишу модификаторы 'public abstract' у методов и 'public static final' у полей.

лично мне важна одинаковость деклараций, чтобы не думать, смотрю я интерфейс или класс, чтобы для копипаста годился любой попавшийся под руку файл .java...

Здравствуйте, C0s.

C0s>лично мне важна одинаковость деклараций, чтобы не думать, смотрю я интерфейс или класс, чтобы для копипаста годился любой попавшийся под руку файл .java...

Копипаст это конечно круто. А не пробовали использовать средства IDE? Говорят, удобно.

Здравствуйте, msqrt84, Вы писали:

C0s>>лично мне важна одинаковость деклараций, чтобы не думать, смотрю я интерфейс или класс, чтобы для копипаста годился любой попавшийся под руку файл .java...

M>Копипаст это конечно круто. А не пробовали использовать средства IDE? Говорят, удобно.

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

Здравствуйте, C0s.

M>>Копипаст это конечно круто. А не пробовали использовать средства IDE? Говорят, удобно.

C0s>этот вопрос, конечно, был предсказуем...

Я и не сомневаюсь.

C0s>мой многолетний опыт программирования в простых редакторах мне позволяет утверждать, что новомодные средства современных ide в общем случае не помогают быстрее писать качественный код. не мешают, но и не помогают

Кто про лук, кто про чеснок.

Для достижения банальной одинаковости деклараций можно использовать банальные же средства любой IDE: перегрузка/переопределение методов, ввод членов класса и т.д. Эти возможности просто незаменимы при необходимости соблюдать одинаковость кода при командой работе. И не спорьте.

При чём здесь Ваш многолетний опыт и новомодные средства современных IDE мне не очень понятно. Хотя если хочется похвастаться многолетним опытом, то пожалуйста.

Здравствуйте, msqrt84, Вы писали:

M>Для достижения банальной одинаковости деклараций можно использовать банальные же средства любой IDE: перегрузка/переопределение методов, ввод членов класса и т.д. Эти возможности просто незаменимы при необходимости соблюдать одинаковость кода при командой работе. И не спорьте.

это возможно только путём насаждения определённых ide на команду. опыт же показывает, что это излишнее требование, т.к. вместо поиска недовольных лучше не вводить лишних ограничений на использование "только таких" инструментов. из "только таких" в большинстве случаев принимается только ant.

M>При чём здесь <...> новомодные средства современных IDE мне не очень понятно.

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

Здравствуйте, C0s.

C0s>это возможно только путём насаждения определённых ide на команду. опыт же показывает, что это излишнее требование, т.к. вместо поиска недовольных лучше не вводить лишних ограничений на использование "только таких" инструментов. из "только таких" в большинстве случаев принимается только ant.

Необязательно. У большинства современных IDE есть один и тот же базовый набор средств.

M>>При чём здесь <...> новомодные средства современных IDE мне не очень понятно.

C0s>при том, что первоначальный пассаж про ide был не мой?

Именно, при том, что "новомодные средства", которые Вы ввели в разговор, не имеют особого смысла в данном контексте.

C0s>неоднократно наблюдал, как люди в своей массе, используя ide, не достигают качества. не важно почему, может, потому, что они не проходили "школу", и доверяют ide слишком сильно или считают, что "раз программа написана с помощью ide, она по определению не хуже, чем надо", может ещё по каким причинам. это был мой ответ. опыт же был упомянут лишь для того, чтобы утверждать "я неоднократно наблюдал" вместо "я где-то слышал". за ними приходится проверять. final при анализе кода помогает, что ещё надо?

Если final Вам помогает при анализе кода, то ради бога. Мне наличие этого модификатора никак не помогает. Что есть, что нет. Для тестирования и подавно.

Современные IDE помогают при программировании/разработке, и ещё как. Просто та масса, о которой Вы говорите, не умеет этими IDE пользоваться, а лишь думает, что умеет.

Здравствуйте, rsn81, Вы писали:

R>Не неправильно, просто на айсберге видите только его верхушку. Читайте: Теория и практика Java: Изменять или не изменять? Неизменяемые объекты могут значительно облегчить вашу жизнь.

Спасибо, я и расчитывал на ссылку на какой-нить FAQ

>"банальный пример String a += somestring, работающий в цикле" — никогда так не делайте. Сжираете память: при каждой конкатенации создаётся новый объект с соответствующим выделением памяти под строку. Для таких целей нужно использовать StringBuffer/StringBuilder (они mutable). Про строки тут хорошо написано.

Да знаю я про это, шишку давно набил и даже когда о жабе слышал только по телеку.

>При какой-либо операции с List ссылка на объект поменялась и всё.

А при каком-либо изменении поля объекта поле поменялось и все. Тогда получается что любой объект immutable, потому что ссылка на него постоянна? Но ведь это не так.

Здравствуйте, Аноним.

А>А при каком-либо изменении поля объекта поле поменялось и все. Тогда получается что любой объект immutable, потому что ссылка на него постоянна? Но ведь это не так.

Мыслите проще. Понятие "immutable" означает, что Вы никогда не сможете поменять содержимое объекта. Ссылка тут ни при чём. Использовать ли в качестве поля для хранения ссылки на immutable объект переменную или константу, не имеет никакого значения.

Выделите для себя 2 понятия:
1) изменяемость переменной для хранения ссылки на объект;
2) изменяемость объекта.
По первому пункту имеется ввиду модификатор final. По второму — как реализуете.

Если ссылка на объект постоянна, это не означает, что объект неизменяемый. Ещё раз: термин "immutable" относится к объекту, а не к его ссылке.

Если Вы понимаете в чём фишка конкатенации строк в цикле, то не совсем понятно в чём тогда трудность.

Immutable means unchangeable. In Java, when an object is defined as being immutable it means that once it has been initialized its state cannot be changed.

Источник

	От:	Аноним
	Дата:	01.03.09 13:36
	Оценка:

	От:	Аноним
	Дата:	01.03.09 15:40
	Оценка:	+1

	От:	Аноним
	Дата:	01.03.09 16:34
	Оценка:

От:	rsn81	http://rsn81.wordpress.com
Дата:	01.03.09 17:06
Оценка:	2 (2)

	От:	Nicht
	Дата:	02.03.09 07:54
	Оценка:

От:	denis.zhdanov	http://denis-zhdanov.blogspot.com/
Дата:	03.03.09 06:44
Оценка:

От:	mkizub	http://symade.tigris.org
Дата:	03.03.09 10:18
Оценка:

	От:	Игорь
	Дата:	04.03.09 06:30
	Оценка:

	От:	C0s
	Дата:	04.03.09 12:50
	Оценка:	+1

	От:	C0s
	Дата:	04.03.09 12:53
	Оценка:

	От:	C0s
	Дата:	04.03.09 13:21
	Оценка:	+1