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


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

Аннотация:
Официально язык Java поддерживает только объектно-ориентированную парадигму, которая не всегда позволяет сделать код компактным, легко читаемым и удобным в поддержке. Однако Java-гуру умудряются использовать имеющиеся в Java возможности для применения в Java-коде функционального стиля программирования, который в некоторых случаях позволяет радикально улучшить читаемость кода (делая его более декларативным), а также упростить его поддержку и развитие. Надеемся, что данная статья будет полезна многим Java-программистам разного уровня.
Большая часть данной статьи не имеет отношения к собственно функциональному программированию (далее – ФП). В основном будут рассмотрены способы повышения читаемости некоторых часто встречающихся паттернов, особенно при использовании функционального стиля, и без которых об ФП не может быть и речи. О приемах собственно ФП будет сказано совсем немного, ближе к концу статьи.
Re[6]: Приемы программирования на Java
От: elmal  
Дата: 04.01.09 08:21
Оценка: 5 (3) +2 -2 :)))
Здравствуйте, Аноним, Вы писали:

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

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

Я это все к тому, что путем возвращения от программирования на фреймворках, которое действительно что-то чересчур модно, к программированию с использованием фреймворков и максимальному использованию Java можно очертененно ускорить разработку. А когда пишешь с использованием нормального ЯП, то очень было бы нелишним задуматься об эффективных техниках улучшения читаемости кода, что далеко не очевидно.
Re: Приемы программирования на Java
От: vip_delete  
Дата: 24.08.09 19:13
Оценка: +1 -3
Вставлю свои 5 копеек. Статья из серии холивара, как надо писать и как не надо.

Мне, например, не все приемы из статьи понравились, а некоторые доведены до абсурда.

1. Вначале статьи автор пишет, что будет бороться с "kingdom of nouns", а потом предлагает для большей читаемость насоздавать кучу своих классов и используя static import заимпортировать в свои классы. Например, класс

public abstract class Filters 
{
  public static Filter and(Filter a, Filter b) {return new AndFilter(a,b);}
}


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

Filter f = new AndFilter(first, second);


То же самое можно сказать про "Конструкторы с сигнатурами базового класса". Если это пустые классы, то это как раз те самые "kingdom of nouns", с которыми борется автор.

2. На мой взгляд, главное, чтобы код читался хорошо, хотя бы теми кто его пишет. Например, код

private static final Set<String> INTERESTING_TAGS = 
  set("A","FORM","INPUT","SCRIPT","OBJECT");


совсем нечитабелен. Какой тут Set: HashSet? TreeSet? UnmodifiableSet? А почему метод set выделен только для HashSet? Автор только один тип set'а использует?

3. Далее, static import — это зло, так как из предыдущего кода можно подумать, что set — это метод текущего класса. Ну и везде в статье, якобы, static import уменьшает кол-во кода, а значит увеличивает читаемость. Это не так.

4. В коде

Map<String,Integer> WEIGHTS = zipMap(
  ar("bad", "poor", "average", "nice", "outstanding"),
  ar(-2,    -1,     0,         1,      3));


есть один недостаток: после форматирования получается

Map<String, Integer> WEIGHTS = zipMap(
        ar("bad", "poor", "average", "nice", "outstanding"),
        ar(-2, -1, 0, 1, 3));


согласитеть, уже не очевидно, что кол-во ключей равно кол-во значений, а это рано или поздно приведет к RuntimeException.

5. Кое что в статье боян. Например код

public class CollectionFactory 
{
  public static <K,V> Map<K,V> newMap() 
  {
   return new HashMap<K,V>();
  }
}


уже был более года назад был написан в Google Collections:

package com.google.common.collect;

public final class Maps {
  public static <K, V> HashMap<K, V> newHashMap() {
    return new HashMap<K, V>();
  }

  public static <K, V> LinkedHashMap<K, V> newLinkedHashMap() {
    return new LinkedHashMap<K, V>();
  }

  public static <K extends Comparable, V> TreeMap<K, V> newTreeMap() {
    return new TreeMap<K, V>();
  }
}


5. Я согласен с jkff, что главное это бизнес требования. Все остальное сделает IDE: сгенерит, подставит, заимпортирует ну, и Apache Commons или Google Collections, кому нравится, помогают. Нам, java-программистам, можно не заморачиваться на синтаксический сахар
Re[7]: Приемы программирования на Java
От: Аноним  
Дата: 31.12.08 08:45
Оценка: -2
А>>В джаве, в том то и дело, прикол не в языке.

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


Java, как язык, может скоро умереть от прихода многопроцессорности.
Ну да ладно.
Re[2]: Приемы программирования на Java
От: Baudolino  
Дата: 24.08.09 19:57
Оценка: +2
_> ...Например, класс
_>
_>public abstract class Filters 
_>{
_>  public static Filter and(Filter a, Filter b) {return new AndFilter(a,b);}
_>}
_>

_>совершенно бесполезен, если он решает только проблему якобы "плохочитаемого кода" типа
_>
_>Filter f = new AndFilter(first, second);
_>

Вы внезапно забыли, что фильтры комбинируются и запись and(or(f1,f2),not(f3)) все же компактнее и проще для восприятия, чем куча конструкторов.

_>2. На мой взгляд, главное, чтобы код читался хорошо, хотя бы теми кто его пишет. Например, код

_>
_>private static final Set<String> INTERESTING_TAGS = 
_>  set("A","FORM","INPUT","SCRIPT","OBJECT");
_>

_>совсем нечитабелен.
Очень даже читабелен. Надо понимать, что автор показал направление (о чем там явно сказано), а не взял на себя труд реализовывать идеальную библиотеку. В данном случае может быть например constSet(...).
_>А почему метод set выделен только для HashSet? Автор только один тип set'а использует?
Обзовите его hashSet или newHashSet как в Google Collections, если вам это важно. Но конкретная реализация структуры далеко не всегда важна, поэтому можно выбрать и более компактную запись.

_>3. Далее, static import — это зло, так как из предыдущего кода можно подумать, что set — это метод текущего класса. Ну и везде в статье, якобы, static import уменьшает кол-во кода, а значит увеличивает читаемость. Это не так.

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

_>5. Кое что в статье боян.

Ну, положим, текст статьи в ЖЖ я видел больше, чем год назад. Прежде чем что-либо назвать баяном, обратите внимание на дату материала появления в первоисточнике. Да и не важно это всё.

_>Нам, java-программистам, можно не заморачиваться на синтаксический сахар

Не знаю как вам, java-программистам, а нам, java-программистам, можно и заморочиться.
Re: Приемы программирования на Java
От: rsn81 Россия http://rsn81.wordpress.com
Дата: 18.01.09 13:33
Оценка: 6 (1)
Здравствуйте, Евгений Кирпичев aka jkff, Вы писали:

[skipped]
В вашей главе "Увеличиваем читаемость generic-ов — typedef для бедных" предлагается в частных случаях использовать то, что в общем случае является антрипаттерном. Без детального указания области применения такая рекомендация выглядит крайне некорретно. Советую ознакомиться со статьей: Теория и практика Java: Антишаблон pseudo-typedef — и внести соответствующие изменения в рекомендацию вашей статьи.
Re: Приемы программирования на Java
От: abch-98-ru Россия  
Дата: 01.01.09 19:19
Оценка: 3 (1)
Ссылка, которая якобы на статью — на деле, ссылка на оглавление.
Вранье — это нехорошо.

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

ЕК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>

В целом — по сути неплохо, по реализации — "сырость". Голосовать рублем не буду
Re[4]: Приемы программирования на Java
От: Blazkowicz Россия  
Дата: 06.02.09 13:59
Оценка: 2 (1)
Здравствуйте, techgl, Вы писали:

T>>>А то в Java параметризировать методы нельзя.

B>>Можно.
T>Статические, как я понял, нельзя. Или приведи пример, какой код будет компилироваться, пожалуйста.

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

Там как раз пропущен указатель на то что метод Generic.
Re: Приемы программирования на Java
От: Аноним  
Дата: 31.12.08 03:21
Оценка: -1
Евгений, ваша статья, — а я смотрел презентацию JavaFP_ru.ppt, — немножко оторванна от реалий.
Вы так и не поняли что Джава — это не прогарммирование вообще, а кодинг бизнес-требований.
Нам и так хорошо. Многие из нас JDBC используют раз в 3 года.
Re[2]: Приемы программирования на Java
От: jkff Россия antilamer.livejournal.com
Дата: 31.12.08 07:31
Оценка: +1
Здравствуйте, Аноним, Вы писали:

А>Евгений, ваша статья, — а я смотрел презентацию JavaFP_ru.ppt, — немножко оторванна от реалий.

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

Боюсь показаться грубым, но то, что статья оторвана от Ваших реалий, что Вам и так хорошо и что Вы не считаете нужным использовать потенциал Джавы как языка программирования — это Ваше личное дело и означает лишь, что лично для Вас статья бесполезна
Я же повседневно использую все, что в статье упоминается, и мне это очень помогает увеличивать и читаемость, и продуктивность, и, в конце концов, корректность (как раз недавно выловил несколько багов-от-невнимательности, ставших очевидными после введения конвенции key_value, например). Коллеги тоже кое-что используют, хоть и далеко не все. Статья написана не "от балды", а по горячим следам моей собственной практики.
Re[5]: Приемы программирования на Java
От: Аноним  
Дата: 31.12.08 08:09
Оценка: -1
Здравствуйте, 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.
ФП — это вообще другой подход к мышлению. Очень многих джава кодеров можно привести в ступор от ФП техник.
В джаве, в том то и дело, прикол не в языке.
Re[8]: Приемы программирования на Java
От: messir VolanD Беларусь http://www.google.com/profiles/p.drobushevich
Дата: 31.12.08 09:53
Оценка: :)
Здравствуйте, Аноним, Вы писали:

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


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


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


А можно по подробнее, просто наш проект на java эффективно работает на сановском сервере с 2 десятками процессоров, не понятно что мы не правидлно делаем?)))))) Да и вообще я думал многопроцессорность уже давно пришла, очень давно
Re[8]: Приемы программирования на Java
От: Аноним  
Дата: 01.01.09 00:45
Оценка: :)
Здравствуйте, Аноним, Вы писали:

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

А>Ну да ладно.

Олололо! Еще шапочку не забудь надеть, а то торсионные поля кругом. И это правда, как и то, что Microsoft предрек скорую кончину жабе. В 2001 году.
Re[6]: Приемы программирования на Java
От: inopressa Россия  
Дата: 04.01.09 07:27
Оценка: :)
Здравствуйте, <Аноним>, Вы писали:

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


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

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

Дык кому-то конфигурировать фреймворки, а кому-то их и писать надо ))
... << RSDN@Home 1.2.0 alpha rev. 787>>
Re[5]: Приемы программирования на Java
От: mazurkin http://mazurkin.info
Дата: 25.08.09 06:13
Оценка: +1
elmal wrote:

> Мапы часто используются статические. Соответственно такой записью я

> избавляюсь от static секции. Во вторых, в случае, если я
> инициализирую список подобным образом, у меня сразу видно количество
> элементов, и я могу при создании списка просетать это значение -
> мелочь, а приятно. Тоже самое с мапкой, если мне надо будет
> реализовывать BycicleMap, то я смогу использовать эту информацию, и
> нахаляву получить достаточно оптимальную реализацию.

.... и тут же создаете N совершенно ненужных инстансов классов через
mapEntry

Насчет статической секции — я тоже не люблю статические секции. Поэтому
возможно создал бы мэпу с настройками отдельным синглтоном и использовал
бы ее.

> Очень плохо читается во первых. Во вторых, компилятор корректность

> этих пропертей не сможет проверить. Сложности с рефакторингом (да, я
> знаю что у большинства рефакторинг не в почете). В третьих, часто
> константы мапишь на обработчик, соответственно проперти не катят.
> Относительно спринга — одновременно и плохо читается, и плохо
> поддерживается. spring очень хорошая штука, вот только употреблять ее
> надо к месту, а не городить километровые XML в которых сам черт ногу
> сломит, и пытаясь вообще все запихнуть в XML.

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

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

> PS Избавившись от логики непосредственно в спринговой конфигурации

> удалось время разработки уменьшить раз в 10 по сравнению с теми, кто
> на XML молился. Более того, протестировать удалось лучше, багов
> вообще не оказалось

Мне кажется вы сильно сейчас приукрасили все — у вас XML-фобия просто

Не надо молиться на XML — вынос конфигурации в IoC уменьшает сцепление
между классами и увеличивает связность внутри классов, что отражается
однозначно положительным образом на качестве кода и общей архитектуре. А
абстрактные баги лечатся совершенно конкретными тестами.
Posted via RSDN NNTP Server 2.1 beta
Re[3]: Приемы программирования на Java
От: Аноним  
Дата: 31.12.08 07:40
Оценка:
Здравствуйте, jkff,

продолжайте дальше изучать ФП и не трогайте больше джаву.
Re[4]: Приемы программирования на Java
От: jkff Россия antilamer.livejournal.com
Дата: 31.12.08 07:59
Оценка:
Здравствуйте, Аноним, Вы писали:

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


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


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

Почему Вы считаете, что в джаве эти приемы неуместны? "Потому что джава — для выполнения бизнес-требований" — не аргумент; каким бы скучным требование ни было, необходимость реализовать его красивым, читаемым и лаконичным кодом никуда не девается; да и не у всех и не всегда, в конце концов, такие уж скучные и мелкие требования, чтобы ничего не оставалось, кроме как скрепя сердце писать boilerplate.
Re[6]: Приемы программирования на Java
От: jkff Россия antilamer.livejournal.com
Дата: 31.12.08 08:32
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, 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 как таковые (я не люблю ), но это отдельный спор.

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


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

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


Ну а я, вот, нашел в ней и этот прикол
Re[9]: Приемы программирования на Java
От: jkff Россия antilamer.livejournal.com
Дата: 01.01.09 16:48
Оценка:
Здравствуйте, messir VolanD, Вы писали:

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


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


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


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


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


Умереть-то, конечно, не умрет, но все же программировать параллельные штуки на функциональных языках гораздо легче. Вещи типа STM в не-чистом языке невозможны вовсе; вещи типа "параллельных стратегий" Хаскелла (это самое красивое, что я вообще видел в мире параллельного программирования) невозможны в не-ленивом языке.
Так что слухи о смерти Джавы преждевременны, но думаю, что пару процентов "рынка" в мире параллельщины она уступит
Re: Приемы программирования на Java
От: Аноним  
Дата: 01.01.09 20:43
Оценка:
Здравствуйте, Евгений Кирпичев aka jkff, Вы писали:

ЕКA>Статья:

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


А где можно статью прочитать, кроме журнала в бумажном виде?
Или это сейчас невозможно?
Re[2]: Приемы программирования на Java
От: elmal  
Дата: 18.01.09 15:18
Оценка:
Здравствуйте, rsn81, Вы писали:

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

Аргументация что это антипаттерн ИМХО весьма спорная. Проблемы повторного использования, слишком конкретны и т.д — их просто надо применять там, где требуется, и все будет хорошо. Если требуется повторное использование, то в контрактах ничего не мешает использовать родительский абстрактный тип, и все проблемы повторного использования и недостаточной обобщенности это снимет. А если от псевдотипов отказываться по религиозным убеждением, то придется отказаться и от использования логики на достаточно сложных дженериках, так как читать вложенные громоздкие дженерики очень тяжело, и в результате вводить дублирование логики, писать приведение типов. А автору не нравится что конструкторы в производных классах придется переопределять — это вообще не проблема по сравнению с тем, какую выгоду можно получить от псевдотипов.
Re[3]: Приемы программирования на Java
От: rsn81 Россия http://rsn81.wordpress.com
Дата: 18.01.09 17:49
Оценка:
Здравствуйте, elmal, Вы писали:

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

Во-первых, аргументации у Брайана Гетца в указанной статье хватает, мне незачем было его повторять. Во-вторых, в замечании не зря было указано, что не описана область применения указанной рекомендации: если сказать, что "в таких-то и таких-то случаях, получая такие-то минусы, можно, в принципе, сделать так" — то никаких проблем бы не было. В-третьих, композитные типы не так уж и сложны, как поется, религиозные убеждения — это скорее двигаться в сторону кажущейся простоты, не думая, к чему это приведет.
Re[6]: Приемы программирования на Java
От: mselez  
Дата: 20.01.09 04:59
Оценка:
Здравствуйте, Аноним, Вы писали:

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


Хорошо сказано. У меня уже давно тоскливое ощущение, что java программирование мутирует в java администрирование (редактирование xml файлов). А имя этому — "энтерпрайз". И сайты по поиску работы это различают. Все же еще есть вакансии по java core, и там буквально пишут, что не J2EE.
Re: Приемы программирования на Java
От: techgl  
Дата: 06.02.09 13:47
Оценка:
Здравствуйте, Евгений Кирпичев aka jkff, Вы писали:

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

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

}

Это просто прототип решения? А то в Java параметризировать методы нельзя.
Как должен выглядеть рабочий вариант?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Приемы программирования на Java
От: Blazkowicz Россия  
Дата: 06.02.09 13:50
Оценка:
Здравствуйте, techgl, Вы писали:

T>А то в Java параметризировать методы нельзя.

Можно.
Re[3]: Приемы программирования на Java
От: techgl  
Дата: 06.02.09 13:54
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

T>>А то в Java параметризировать методы нельзя.

B>Можно.
Статические, как я понял, нельзя. Или приведи пример, какой код будет компилироваться, пожалуйста.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Приемы программирования на Java
От: mazurkin http://mazurkin.info
Дата: 06.02.09 14:00
Оценка:
techgl wrote:
> Здравствуйте, Евгений Кирпичев aka jkff, Вы писали:
>
> Хорошая статья.
> Однако столкнулся с непонятной реализацией. Речь о помощнике для статических коллекций. Из статьи:
>
> public class CollectionUtils {
> 
>   public static Set<T> set(T... ts) {
>     return new HashSet<T>(Arrays.asList(ts));
>   }
> 
> }
>


Вообще вот так должно быть

    public static <T> Set<T> set(T... ts) {
        return new HashSet<T>(Arrays.asList(ts));
    }
Posted via RSDN NNTP Server 2.1 beta
Re[5]: Приемы программирования на Java
От: techgl  
Дата: 06.02.09 14:03
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

B>Там как раз пропущен указатель на то что метод Generic.

Да, невнимательно посмотрел в спецификацию. Спасибо.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: Приемы программирования на Java
От: DenLion Россия  
Дата: 24.08.09 14:42
Оценка:
Здравствуйте, Евгений Кирпичев aka jkff, Вы писали:

ЕКA>Статья:

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


Очень интересная статья, спасибо. Но есть одно некоторые ньюансы: у нас в проекте есть блок статической
инициализации мапа из более чем 4ёх десятков строк для пары ключ->значение, где каждый
ключ и каждое значение есть стринг из более чем 30ти (до 50ти) символов. В таком случае, мне кажется,
читаемость "обычного стиля" (someMap.put(CONSTANT_WITH_LONG_NAME, "anotherStringConstant")) будет
выше. При попытке перевести эту громадину на предлагаемый вами стиль получится страшная каша.
Re[2]: Приемы программирования на Java
От: elmal  
Дата: 25.08.09 05:02
Оценка:
Здравствуйте, DenLion, Вы писали:

DL>читаемость "обычного стиля" (someMap.put(CONSTANT_WITH_LONG_NAME, "anotherStringConstant")) будет

DL>выше. При попытке перевести эту громадину на предлагаемый вами стиль получится страшная каша.
Я делаю так:

Map map = CollectionUtils.map(mapEntry(CONSTANT_WITH_LONG_NAME,  "anotherStringConstant"),
                              mapEntry(CONSTANT_WITH_LONG_NAME1, "anotherStringConstant1"),
                              mapEntry(CONSTANT_WITH_LONG_NAME2, "anotherStringConstant2"),
                              mapEntry(CONSTANT_WITH_LONG_NAME3, "anotherStringConstant3"));

Это я к тому, что всегда можно улучшить то, что предлагают другие. А статья неплохая, я многими способами стал пользоваться. Очень было б неплохо, чтоб хотя бы 20% задумывались бы о стиле, послоянно думая, как можно написать лучше.
Re[3]: Приемы программирования на Java
От: mazurkin http://mazurkin.info
Дата: 25.08.09 05:36
Оценка:
elmal wrote:
>
> Map map = CollectionUtils.map(mapEntry(CONSTANT_WITH_LONG_NAME,  "anotherStringConstant"),
>                               mapEntry(CONSTANT_WITH_LONG_NAME1, "anotherStringConstant1"),
>                               mapEntry(CONSTANT_WITH_LONG_NAME2, "anotherStringConstant2"),
>                               mapEntry(CONSTANT_WITH_LONG_NAME3, "anotherStringConstant3"));
>

> Это я к тому, что всегда можно улучшить то, что предлагают другие.

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

Map<A,B> map = new HashMap<A,B>();
map.put(CONSTANT_WITH_LONG_NAME,  "anotherStringConstant");
map.put(CONSTANT_WITH_LONG_NAME1, "anotherStringConstant1");
map.put(CONSTANT_WITH_LONG_NAME2, "anotherStringConstant2");
map.put(CONSTANT_WITH_LONG_NAME3, "anotherStringConstant3");


Во-вторых, лично я выношу подобные константные мэпы либо во внешние
properties-файлы, либо делаю инжекцию через IoC-контейнер спринга.
Posted via RSDN NNTP Server 2.1 beta
Re[4]: Приемы программирования на Java
От: elmal  
Дата: 25.08.09 05:58
Оценка:
Здравствуйте, mazurkin, Вы писали:

M>Во-первых, мой мозг отказывается понимать: чем всех вас не устраивает

M>стандартный стиль? Вот я не вижу никаких преимуществ в ваших конструкциях...
Мапы часто используются статические. Соответственно такой записью я избавляюсь от static секции. Во вторых, в случае, если я инициализирую список подобным образом, у меня сразу видно количество элементов, и я могу при создании списка просетать это значение — мелочь, а приятно. Тоже самое с мапкой, если мне надо будет реализовывать BycicleMap, то я смогу использовать эту информацию, и нахаляву получить достаточно оптимальную реализацию.

M>Во-вторых, лично я выношу подобные константные мэпы либо во внешние

M>properties-файлы, либо делаю инжекцию через IoC-контейнер спринга.
Очень плохо читается во первых. Во вторых, компилятор корректность этих пропертей не сможет проверить. Сложности с рефакторингом (да, я знаю что у большинства рефакторинг не в почете). В третьих, часто константы мапишь на обработчик, соответственно проперти не катят. Относительно спринга — одновременно и плохо читается, и плохо поддерживается. spring очень хорошая штука, вот только употреблять ее надо к месту, а не городить километровые XML в которых сам черт ногу сломит, и пытаясь вообще все запихнуть в XML.

PS Избавившись от логики непосредственно в спринговой конфигурации удалось время разработки уменьшить раз в 10 по сравнению с теми, кто на XML молился. Более того, протестировать удалось лучше, багов вообще не оказалось
Re[4]: Приемы программирования на Java
От: komaz Россия  
Дата: 25.08.09 06:08
Оценка:
Здравствуйте, mazurkin, Вы писали:

M>elmal wrote:

>>
>> Map map = CollectionUtils.map(mapEntry(CONSTANT_WITH_LONG_NAME,  "anotherStringConstant"),
>>                               mapEntry(CONSTANT_WITH_LONG_NAME1, "anotherStringConstant1"),
>>                               mapEntry(CONSTANT_WITH_LONG_NAME2, "anotherStringConstant2"),
>>                               mapEntry(CONSTANT_WITH_LONG_NAME3, "anotherStringConstant3"));
>>

>> Это я к тому, что всегда можно улучшить то, что предлагают другие.

M>Во-первых, мой мозг отказывается понимать: чем всех вас не устраивает

M>стандартный стиль? Вот я не вижу никаких преимуществ в ваших конструкциях...

M>
M>Map<A,B> map = new HashMap<A,B>();
M>map.put(CONSTANT_WITH_LONG_NAME,  "anotherStringConstant");
M>map.put(CONSTANT_WITH_LONG_NAME1, "anotherStringConstant1");
M>map.put(CONSTANT_WITH_LONG_NAME2, "anotherStringConstant2");
M>map.put(CONSTANT_WITH_LONG_NAME3, "anotherStringConstant3");
M>


M>Во-вторых, лично я выношу подобные константные мэпы либо во внешние

M>properties-файлы, либо делаю инжекцию через IoC-контейнер спринга.

Как минимум — в первом случае это можно засунуть прям в инициализацию члена класса. После этого откуда угодно сделав Open declaration в IDE видим инициализацию. Во втором случае код придется класть в static {} блок (или в конструктор для нестатичных членов)
Re[5]: Приемы программирования на Java
От: mazurkin http://mazurkin.info
Дата: 25.08.09 07:05
Оценка:
komaz wrote:

> Во втором случае код придется класть в static {} блок (или в конструктор для нестатичных членов)


Вы все — статикофобы!

Вот вам псевдо-функциональный инициализатор...

import java.util.HashMap;
import java.util.Map;

public final class MapComposer<K,V> {

    private Map<K, V> map;

    private MapComposer(Map<K, V> map) {
        this.map = map;
    }

    public static <K,V> MapComposer<K,V> init(Map<K,V> map) {
        return new MapComposer<K,V>(map);
    }

    public static <K,V> MapComposer<K,V> initHashMap(Class<K> k,
Class<V> v) {
        return new MapComposer<K,V>(new HashMap<K,V>());
    }

    public Map<K, V> map() {
        return map;
    }

    public MapComposer<K,V> entry(K key, V value) {
        map.put(key, value);
        return this;
    }

}


import java.util.Date;
import java.util.HashMap;
import java.util.Map;

public class Application {

    private Map<Integer, Long> map1 =
            MapComposer.initHashMap(Integer.class, Long.class).
            entry(1, 20L).
            entry(2, 30L).
            entry(3, 40L).
            map();

    private Map<String, Date> map2 =
            MapComposer.init(new HashMap<String, Date>()).
            entry("1", new Date(1)).
            entry("2", new Date(2)).
            entry("3", new Date(3)).
            map();

    public static void main(String[] args) throws Exception {
        Application application = new Application();
    }
}
Posted via RSDN NNTP Server 2.1 beta
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.