Думаю не редка ситуация когда нужно обратится к одному элементу массива (не важно какому) и получить некоторое свойство. Например у нас массив работников департамента, у каждого объекта есть метод возвращающий идентификатор департамента. Как лучше получить этот идентификатор, имеет ли первый метод выигрыш по производительности относительно второго? И красивее ли второй метод первого по вашему мнению? Как делаете сами?

Проверку на то что массив длиной больше 0 вынесена за скобки.

Метод 1

long dept = workers[0].getDeptId();
// или
long dept = workers.get(0).getDeptId();

Метод 2

long dept;
for (Worker worker : workers) {
    dept = worker.getDeptId();
    break;
}

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

А>Думаю не редка ситуация когда нужно обратится к одному элементу массива (не важно какому) и получить некоторое свойство. Например у нас массив работников департамента, у каждого объекта есть метод возвращающий идентификатор департамента. Как лучше получить этот идентификатор, имеет ли первый метод выигрыш по производительности относительно второго? И красивее ли второй метод первого по вашему мнению? Как делаете сами?

А>Проверку на то что массив длиной больше 0 вынесена за скобки.

А>Метод 1
А>

А>long dept = workers[0].getDeptId();
А>// или
А>long dept = workers.get(0).getDeptId();
А>

А>Метод 2
А>

А>long dept;
А>for (Worker worker : workers) {
А>    dept = worker.getDeptId();
А>    break;
А>}
А>

если учесть, что для массивов реализация цикла for each(второй случай) выглядит как обычный цикл перебора массива, то разницы нет. Сделан только для более удобной читабельности. Если обращаться к одному конкретному элементу массива, то лучше по индексу, конечно. Если вам его искать перебором, то разницы нет.

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

А>имеет ли первый метод выигрыш по производительности относительно второго?
Даже если и имеет, то производительность в данном вопросе на 10-м месте. Главное читабельность, устойчивость к изменениям и ошибкам. Разница в производительность здесь нивелируется остальной логикой и, например, работой с БД,

А>И красивее ли второй метод первого по вашему мнению? Как делаете сами?
Второй красивее, потому что уже есть проверка на пустую коллекцию. Потому что во втором случае не важно массив там или коллекция. И потому что первый способ не работает, например, для Set.

А>Проверку на то что массив длиной больше 0 вынесена за скобки.
В любом случае коробит, когда такую проблему надо решать. А что если в коллекцию закрался кто-то из другого департамента?

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

А>>Проверку на то что массив длиной больше 0 вынесена за скобки.
B>В любом случае коробит, когда такую проблему надо решать. А что если в коллекцию закрался кто-то из другого департамента?

А кстати в Java 8 можно будет extension method'ы для массивов делать? Такое в экстеншн прямо таки просится.

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

А>Думаю не редка ситуация когда нужно обратится к одному элементу массива (не важно какому) и получить некоторое свойство. Например у нас массив работников департамента, у каждого объекта есть метод возвращающий идентификатор департамента. Как лучше получить этот идентификатор, имеет ли первый метод выигрыш по производительности относительно второго? И красивее ли второй метод первого по вашему мнению? Как делаете сами?
Во первых, если б потребовалось такое делать, меня б очень беспокоило — именно в этой постановке задачи есть подозрение, что с дизайном что то не так. Хотя грешен, есть у меня места, где приходится делать подобное, рано или поздно разгребу.
Итого — лично у меня что то вроде такого в таком случае:

    long dept = DataExtractors.getDeptId(workers);

А как это внутри реализовано — пофиг абсолютно, главное чтоб работало как надо.
Лтбо есть еще один вариант, когда workers является аттрибутом более общего класса. В случае, если имеем класс Depertment, который ссылается на этих workers, делаю метод getDeptId для класса Department, реализация неизменна. Уже с внешней стороны дизайн получается нормальный, а внутренности потом подрефакторятся, если необходимость будет.

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

B>Даже если и имеет, то производительность в данном вопросе на 10-м месте. Главное читабельность, устойчивость к изменениям и ошибкам. Разница в производительность здесь нивелируется остальной логикой и, например, работой с БД,
B>Второй красивее, потому что уже есть проверка на пустую коллекцию. Потому что во втором случае не важно массив там или коллекция. И потому что первый способ не работает, например, для Set.

Нужен один элемент по индексу, а код в цикле пробегается по всему массиву? Это совершенно не очевидно и плохо читаемо. Set не совсем в тему, так как речь о массиве.

А>>Проверку на то что массив длиной больше 0 вынесена за скобки.
B>В любом случае коробит, когда такую проблему надо решать. А что если в коллекцию закрался кто-то из другого департамента?

Без проверки на null все равно не обойтись. В этом же месте можно сделать проверку на размер. Или использовать CollectionUtils из commons, если речь именно о размере больше нуля.

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

D>Нужен один элемент по индексу, а код в цикле пробегается по всему массиву? Это совершенно не очевидно и плохо читаемо. Set не совсем в тему, так как речь о массиве.
В цикле break.

D>Без проверки на null все равно не обойтись.
В моём коде массивы и коллекции с null элементами — большая редкость.

D>В этом же месте можно сделать проверку на размер.
D>Или использовать CollectionUtils из commons, если речь именно о размере больше нуля.
Зачем?

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

D>>Нужен один элемент по индексу, а код в цикле пробегается по всему массиву? Это совершенно не очевидно и плохо читаемо. Set не совсем в тему, так как речь о массиве.
B>В цикле break.

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

D>>Без проверки на null все равно не обойтись.
B>В моём коде массивы и коллекции с null элементами — большая редкость.

Если честно, свои проекты не анализировал на этот предмет, просто всегда проверяю на null.

D>>В этом же месте можно сделать проверку на размер.
D>>Или использовать CollectionUtils из commons, если речь именно о размере больше нуля.
B>Зачем?

Использовать один метод для проверки на null и на не пустоту. Аналогично StringUtils. Делает код более читаемым, сокращает писанину.

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

D>Здравствуйте, Blazkowicz, Вы писали:
D>>>Нужен один элемент по индексу, а код в цикле пробегается по всему массиву? Это совершенно не очевидно и плохо читаемо. Set не совсем в тему, так как речь о массиве.
B>>В цикле break.
D>Это все равно не интуитивно понятный код. Стороннему человеку надо будет хорошо подумать, что именно хотел сказать автор. Сделать таким образом проверку на наличие элементов — я бы лично не догадался.
По мне, так явная проверка всегда лучше чем неявная, тем более кодом который используется не по прямому назначению (for). Даже если она более громоздка. Это уменьшает вероятность последующих багов.

D>>>Без проверки на null все равно не обойтись.
B>>В моём коде массивы и коллекции с null элементами — большая редкость.
D>Если честно, свои проекты не анализировал на этот предмет, просто всегда проверяю на null.

D>>>В этом же месте можно сделать проверку на размер.
D>>>Или использовать CollectionUtils из commons, если речь именно о размере больше нуля.
B>>Зачем?
D>Использовать один метод для проверки на null и на не пустоту. Аналогично StringUtils. Делает код более читаемым, сокращает писанину.
А заодно уменьшит количество самописных String и других *Utils которыми бывают завалены проекты.