Статья:
Приемы программирования на Java

Автор(ы): Евгений Кирпичев aka jkff
Дата: 28.12.2008
Официально язык Java поддерживает только объектно-ориентированную парадигму, которая не всегда позволяет сделать код компактным, легко читаемым и удобным в поддержке. Однако Java-гуру умудряются использовать имеющиеся в Java возможности для применения в Java-коде функционального стиля программирования, который в некоторых случаях позволяет радикально улучшить читаемость кода (делая его более декларативным), а также упростить его поддержку и развитие. Надеемся, что данная статья будет полезна многим Java-программистам разного уровня.
Большая часть данной статьи не имеет отношения к собственно функциональному программированию (далее – ФП). В основном будут рассмотрены способы повышения читаемости некоторых часто встречающихся паттернов, особенно при использовании функционального стиля, и без которых об ФП не может быть и речи. О приемах собственно ФП будет сказано совсем немного, ближе к концу статьи.

Авторы:
Евгений Кирпичев aka jkff

Аннотация:
Официально язык Java поддерживает только объектно-ориентированную парадигму, которая не всегда позволяет сделать код компактным, легко читаемым и удобным в поддержке. Однако Java-гуру умудряются использовать имеющиеся в Java возможности для применения в Java-коде функционального стиля программирования, который в некоторых случаях позволяет радикально улучшить читаемость кода (делая его более декларативным), а также упростить его поддержку и развитие. Надеемся, что данная статья будет полезна многим Java-программистам разного уровня.
Большая часть данной статьи не имеет отношения к собственно функциональному программированию (далее – ФП). В основном будут рассмотрены способы повышения читаемости некоторых часто встречающихся паттернов, особенно при использовании функционального стиля, и без которых об ФП не может быть и речи. О приемах собственно ФП будет сказано совсем немного, ближе к концу статьи.

Евгений, ваша статья, — а я смотрел презентацию JavaFP_ru.ppt, — немножко оторванна от реалий.
Вы так и не поняли что Джава — это не прогарммирование вообще, а кодинг бизнес-требований.
Нам и так хорошо. Многие из нас JDBC используют раз в 3 года.

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

А>Евгений, ваша статья, — а я смотрел презентацию JavaFP_ru.ppt, — немножко оторванна от реалий.
А>Вы так и не поняли что Джава — это не прогарммирование вообще, а кодинг бизнес-требований.
А>Нам и так хорошо. Многие из нас JDBC используют раз в 3 года.

Боюсь показаться грубым, но то, что статья оторвана от Ваших реалий, что Вам и так хорошо и что Вы не считаете нужным использовать потенциал Джавы как языка программирования — это Ваше личное дело и означает лишь, что лично для Вас статья бесполезна
Я же повседневно использую все, что в статье упоминается, и мне это очень помогает увеличивать и читаемость, и продуктивность, и, в конце концов, корректность (как раз недавно выловил несколько багов-от-невнимательности, ставших очевидными после введения конвенции key_value, например). Коллеги тоже кое-что используют, хоть и далеко не все. Статья написана не "от балды", а по горячим следам моей собственной практики.

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

продолжайте дальше изучать ФП и не трогайте больше джаву.

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

А>Здравствуйте, jkff,

А>продолжайте дальше изучать ФП и не трогайте больше джаву.

Постараюсь все-таки вытянуть из Вас что-нибудь более конструктивное.

Почему Вы считаете, что в джаве эти приемы неуместны? "Потому что джава — для выполнения бизнес-требований" — не аргумент; каким бы скучным требование ни было, необходимость реализовать его красивым, читаемым и лаконичным кодом никуда не девается; да и не у всех и не всегда, в конце концов, такие уж скучные и мелкие требования, чтобы ничего не оставалось, кроме как скрепя сердце писать boilerplate.

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

J>Почему Вы считаете, что в джаве эти приемы неуместны? "Потому что джава — для выполнения бизнес-требований" — не аргумент; каким бы скучным требование ни было, необходимость реализовать его красивым, читаемым и лаконичным кодом никуда не девается; да и не у всех и не всегда, в конце концов, такие уж скучные и мелкие требования, чтобы ничего не оставалось, кроме как скрепя сердце писать boilerplate.

К примеру, из вашей презентации использовать

Map<Integer, List<String>> namesById = new HashMap();

а не

Map<Integer, List<String>> namesById = new HashMap<Integer, List<String>>();

Означает завалить проект варнингами.

Но это еще ерунда.
Java, как язык, джава программистами очень редко используется.
У нас сотни фреймворков и наша задача — их конфигурация.
Очень много можно сгенерировать и быстро выразить через Eclipse IDE, которая, по сути, уже является бизнес-стандартом.
90% доступа к базе данных уже отдано Hibernate.
ФП — это вообще другой подход к мышлению. Очень многих джава кодеров можно привести в ступор от ФП техник.
В джаве, в том то и дело, прикол не в языке.

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

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

J>>Почему Вы считаете, что в джаве эти приемы неуместны? "Потому что джава — для выполнения бизнес-требований" — не аргумент; каким бы скучным требование ни было, необходимость реализовать его красивым, читаемым и лаконичным кодом никуда не девается; да и не у всех и не всегда, в конце концов, такие уж скучные и мелкие требования, чтобы ничего не оставалось, кроме как скрепя сердце писать boilerplate.

А>К примеру, из вашей презентации использовать

А>

Map<Integer, List<String>> namesById = new HashMap();

А>а не

А>

Map<Integer, List<String>> namesById = new HashMap<Integer, List<String>>();

А>Означает завалить проект варнингами.

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


А>Но это еще ерунда.
А>Java, как язык, джава программистами очень редко используется.

Более чем смелое заявление.

А>У нас сотни фреймворков и наша задача — их конфигурация.

Так что, у Вас на работе единственная задача — конфигурировать фреймворки, и Вы за последний год не написали и 50кб "нормального" кода? Либо не верю, либо срочно меняйте работу.

А>Очень много можно сгенерировать и быстро выразить через Eclipse IDE, которая, по сути, уже является бизнес-стандартом.

Среды облегчают написание отдельных видов boilerplate, но далеко не всего boilerplate. Кроме того, сгенерированный boilerplate еще надо прочитать — читаемость для этого и нужна Необходимость в читаемости никак не затрагивается генерирующими возможностями IDE, и лишь слабо затрагивается их навигационными возможностями.

А>90% доступа к базе данных уже отдано Hibernate.

В некоторых задачах — да. Я же, например, пишу программы, чья активность работы с БД лежит посередине между "нету" и "так много, что без hibernate никуда", и очень доволен тем, что получается писать короткий и полностью контролируемый код, без лишнего уровня абстракции, но и без boilerplate. Не все любят ORM как таковые (я не люблю ), но это отдельный спор.

А>ФП — это вообще другой подход к мышлению. Очень многих джава кодеров можно привести в ступор от ФП техник.

Тут Вы совершенно правы. Но далеко не все из описанных техник имеют отношение к ФП. В аннотации и написано, что большая часть их — просто повышает читаемость и прекрасно применима даже человеком, который про ФП и слыхом не слыхивал, а к ФП они имеют лишь то отношение, что без них ФП на джаве превратится в совершенную кашу.

А>В джаве, в том то и дело, прикол не в языке.

Ну а я, вот, нашел в ней и этот прикол

А>>В джаве, в том то и дело, прикол не в языке.

J>Ну а я, вот, нашел в ней и этот прикол

Java, как язык, может скоро умереть от прихода многопроцессорности.
Ну да ладно.

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

А>>>В джаве, в том то и дело, прикол не в языке.

J>>Ну а я, вот, нашел в ней и этот прикол

А>Java, как язык, может скоро умереть от прихода многопроцессорности.

А можно по подробнее, просто наш проект на java эффективно работает на сановском сервере с 2 десятками процессоров, не понятно что мы не правидлно делаем?)))))) Да и вообще я думал многопроцессорность уже давно пришла, очень давно

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

А>Java, как язык, может скоро умереть от прихода многопроцессорности.
А>Ну да ладно.

Олололо! Еще шапочку не забудь надеть, а то торсионные поля кругом. И это правда, как и то, что Microsoft предрек скорую кончину жабе. В 2001 году.

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

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

А>>>>В джаве, в том то и дело, прикол не в языке.

J>>>Ну а я, вот, нашел в ней и этот прикол

А>>Java, как язык, может скоро умереть от прихода многопроцессорности.

MV>А можно по подробнее, просто наш проект на java эффективно работает на сановском сервере с 2 десятками процессоров, не понятно что мы не правидлно делаем?)))))) Да и вообще я думал многопроцессорность уже давно пришла, очень давно

Умереть-то, конечно, не умрет, но все же программировать параллельные штуки на функциональных языках гораздо легче. Вещи типа STM в не-чистом языке невозможны вовсе; вещи типа "параллельных стратегий" Хаскелла (это самое красивое, что я вообще видел в мире параллельного программирования) невозможны в не-ленивом языке.
Так что слухи о смерти Джавы преждевременны, но думаю, что пару процентов "рынка" в мире параллельщины она уступит

Ссылка, которая якобы на статью — на деле, ссылка на оглавление.
Вранье — это нехорошо.

А да, там еще реклама, где можно купить эту статью. Изящно

ЕКA>Статья:
ЕКA>Приемы программирования на Java

Автор(ы): Евгений Кирпичев aka jkff
Дата: 28.12.2008
Официально язык Java поддерживает только объектно-ориентированную парадигму, которая не всегда позволяет сделать код компактным, легко читаемым и удобным в поддержке. Однако Java-гуру умудряются использовать имеющиеся в Java возможности для применения в Java-коде функционального стиля программирования, который в некоторых случаях позволяет радикально улучшить читаемость кода (делая его более декларативным), а также упростить его поддержку и развитие. Надеемся, что данная статья будет полезна многим Java-программистам разного уровня.
Большая часть данной статьи не имеет отношения к собственно функциональному программированию (далее – ФП). В основном будут рассмотрены способы повышения читаемости некоторых часто встречающихся паттернов, особенно при использовании функционального стиля, и без которых об ФП не может быть и речи. О приемах собственно ФП будет сказано совсем немного, ближе к концу статьи.

ЕКA>Авторы:
ЕКA> Евгений Кирпичев aka jkff

ЕКA>Аннотация:
ЕКA>Официально язык Java поддерживает только объектно-ориентированную парадигму, которая не всегда позволяет сделать код компактным, легко читаемым и удобным в поддержке. Однако Java-гуру умудряются использовать имеющиеся в Java возможности для применения в Java-коде функционального стиля программирования, который в некоторых случаях позволяет радикально улучшить читаемость кода (делая его более декларативным), а также упростить его поддержку и развитие.
"И животноводство!"

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

то, что "Java-гуру умудряются" — отдает самолюбованием и напоминает circulus in definiendo

ЕКA>Надеемся, что данная статья будет полезна многим Java-программистам разного уровня.

ЕКA>Большая часть данной статьи не имеет отношения к собственно функциональному программированию (далее – ФП).
А также к еще 10 вещам. Где в названии можно предположить отношение к ФП, если название статьи "Приемы программирования на Java"?

ЕКA>В основном будут рассмотрены способы повышения читаемости некоторых часто встречающихся паттернов, особенно при использовании функционального стиля, и без которых об ФП не может быть и речи. О приемах собственно ФП будет сказано совсем немного, ближе к концу статьи.

Понимаю... Собственно, название статьи "Приемы программирования на Java" вводит в заблуждение. Создается впечатление, что автор собирается описывать все приемы программирования на java и классифицирует на ФП и не ФП, относящиеся к читаемости... т.е. предельно экономично.

Ну, а презентацию по названию файла нашел и мне в целом понравилось. Хотя и
<imho>
изложенно корявым языком,
с небольшими ошибками — ( использование на слайде 21 to relate без preposition == использованию index или isBetter на слайде 19. если в виду имелась симметричность, так ее вроде нет, а показывать ее лучше на to equal ),
прыжок от читаемости кода к каррингу и монадам — выглядит несообразно, как два разнородных материала — объединенные только личностью автора
в целом как-то непоследовательно изложено. типа на коленке, выдрал из работы с комментариями
</imho>

В целом — по сути неплохо, по реализации — "сырость". Голосовать рублем не буду

Здравствуйте, Евгений Кирпичев aka jkff, Вы писали:

ЕКA>Статья:
ЕКA>Приемы программирования на Java

Автор(ы): Евгений Кирпичев aka jkff
Дата: 28.12.2008
Официально язык Java поддерживает только объектно-ориентированную парадигму, которая не всегда позволяет сделать код компактным, легко читаемым и удобным в поддержке. Однако Java-гуру умудряются использовать имеющиеся в Java возможности для применения в Java-коде функционального стиля программирования, который в некоторых случаях позволяет радикально улучшить читаемость кода (делая его более декларативным), а также упростить его поддержку и развитие. Надеемся, что данная статья будет полезна многим Java-программистам разного уровня.
Большая часть данной статьи не имеет отношения к собственно функциональному программированию (далее – ФП). В основном будут рассмотрены способы повышения читаемости некоторых часто встречающихся паттернов, особенно при использовании функционального стиля, и без которых об ФП не может быть и речи. О приемах собственно ФП будет сказано совсем немного, ближе к концу статьи.

А где можно статью прочитать, кроме журнала в бумажном виде?
Или это сейчас невозможно?

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

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

А>Java, как язык, джава программистами очень редко используется.
А>У нас сотни фреймворков и наша задача — их конфигурация.

Дык кому-то конфигурировать фреймворки, а кому-то их и писать надо ))

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

А>Java, как язык, джава программистами очень редко используется.
Конечно редко, надо же написать свой язык, на основе XML . А в текущем проекте использовать как можно больше языков, чтоб резюме круче смотрелось . Java в резюме будет автоматом, ну и надо в проекте побольше языков заюзать. Я правильно понимаю ?
А>У нас сотни фреймворков и наша задача — их конфигурация.
Также — надо в проекте попробоать прикрутить максимальное количество, чоб резюме смотрелось круче . Я правильно понимаю ?
А>Очень много можно сгенерировать и быстро выразить через Eclipse IDE, которая, по сути, уже является бизнес-стандартом.
Угу, надо написать свой фреймворк, свой ЯП, на основе XML, написать толстенную документацию ко всему этому, кучу плагинов к эклипсу. Опять же, чтоб резюме смотрелось круче. А то, что на чистой Java можно написать быстрее и компактнее, да и еще это можно будет рефакторить и повторно использовать — это мелочи, главное чтоб проект был на миллионы строк и, что главное, для его поддержки и развития требовались тысячи программистов (тогда в резюме можно написать — руководил тысячью программистами, разве не круто ?) .
А>90% доступа к базе данных уже отдано Hibernate.
И что это меняет? Hibernate это почти тоже самое, что и JDBC, отличий при проектировании не так много. Один черт из высокоуровневого кода бизнес требований, непосредственно к Hibernate вменяемые люди не полезут.
А>ФП — это вообще другой подход к мышлению. Очень многих джава кодеров можно привести в ступор от ФП техник.
Очень многих Java кодеров можно в ступор ввести и от ООП техник. Писать же надо так — куча классов со статическими методами, взаимодействующих все со всеми через глобальные переменные . Хотя — какие классы, есть способ лучше — написать вот таким указанным способом свой ЯП надо (обязателно на основе XML, желательно и XML свой придумать), и там уже творить логику даже без процедур с использованием паттерна copy-paste. Все остальные техники вредны, так как уменьшают число людей на проекте и тогда резюме менеджера будет смотреться хуже — бюджет проекта меньше, людей на проекте меньше, разработку сделали быстрее.

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

Здравствуйте, Евгений Кирпичев aka jkff, Вы писали:

[skipped]
В вашей главе "Увеличиваем читаемость generic-ов — typedef для бедных" предлагается в частных случаях использовать то, что в общем случае является антрипаттерном. Без детального указания области применения такая рекомендация выглядит крайне некорретно. Советую ознакомиться со статьей: Теория и практика Java: Антишаблон pseudo-typedef — и внести соответствующие изменения в рекомендацию вашей статьи.

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

R>В вашей главе "Увеличиваем читаемость generic-ов — typedef для бедных" предлагается в частных случаях использовать то, что в общем случае является антрипаттерном. Без детального указания области применения такая рекомендация выглядит крайне некорретно. Советую ознакомиться со статьей: Теория и практика Java: Антишаблон pseudo-typedef — и внести соответствующие изменения в рекомендацию вашей статьи.
Аргументация что это антипаттерн ИМХО весьма спорная. Проблемы повторного использования, слишком конкретны и т.д — их просто надо применять там, где требуется, и все будет хорошо. Если требуется повторное использование, то в контрактах ничего не мешает использовать родительский абстрактный тип, и все проблемы повторного использования и недостаточной обобщенности это снимет. А если от псевдотипов отказываться по религиозным убеждением, то придется отказаться и от использования логики на достаточно сложных дженериках, так как читать вложенные громоздкие дженерики очень тяжело, и в результате вводить дублирование логики, писать приведение типов. А автору не нравится что конструкторы в производных классах придется переопределять — это вообще не проблема по сравнению с тем, какую выгоду можно получить от псевдотипов.

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

E>Аргументация что это антипаттерн ИМХО весьма спорная. Проблемы повторного использования, слишком конкретны и т.д — их просто надо применять там, где требуется, и все будет хорошо. Если требуется повторное использование, то в контрактах ничего не мешает использовать родительский абстрактный тип, и все проблемы повторного использования и недостаточной обобщенности это снимет. А если от псевдотипов отказываться по религиозным убеждением, то придется отказаться и от использования логики на достаточно сложных дженериках, так как читать вложенные громоздкие дженерики очень тяжело, и в результате вводить дублирование логики, писать приведение типов. А автору не нравится что конструкторы в производных классах придется переопределять — это вообще не проблема по сравнению с тем, какую выгоду можно получить от псевдотипов.
Во-первых, аргументации у Брайана Гетца в указанной статье хватает, мне незачем было его повторять. Во-вторых, в замечании не зря было указано, что не описана область применения указанной рекомендации: если сказать, что "в таких-то и таких-то случаях, получая такие-то минусы, можно, в принципе, сделать так" — то никаких проблем бы не было. В-третьих, композитные типы не так уж и сложны, как поется, религиозные убеждения — это скорее двигаться в сторону кажущейся простоты, не думая, к чему это приведет.

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

А>У нас сотни фреймворков и наша задача — их конфигурация.

Хорошо сказано. У меня уже давно тоскливое ощущение, что java программирование мутирует в java администрирование (редактирование xml файлов). А имя этому — "энтерпрайз". И сайты по поиску работы это различают. Все же еще есть вакансии по java core, и там буквально пишут, что не J2EE.

Здравствуйте, Евгений Кирпичев aka jkff, Вы писали:

Хорошая статья.
Однако столкнулся с непонятной реализацией. Речь о помощнике для статических коллекций. Из статьи:

public class CollectionUtils {

  public static Set<T> set(T... ts) {
    return new HashSet<T>(Arrays.asList(ts));
  }

}

Это просто прототип решения? А то в Java параметризировать методы нельзя.
Как должен выглядеть рабочий вариант?