Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 37
Предыдущий перевод этой же статьи собрал 116 комментариев и +98 рейтинга:
habrahabr.ru/blogs/java/112969/
habrahabr.ru/blogs/java/112969/
Возможно я тормоз, но странный у вас синглтон получился. В смысле ничто не мешает несколько экземпляров класса FactorialUtil получить, как с одинаковыми, так и с разными алгоритмами, какой же это синглтон?
Объявляется неделя факториала!
В главе 24 книги «Совершенный код» С. Макконнелл говорит: «Мнение экспертов по этому поводу [программа содержит код, который может когда-нибудь понадобиться] однозначно: если вы хотите наилучшим образом подготовиться к будущим требованиям, не пишите гипотетически нужный код, а уделите повышенное внимание ясности и понятности кода, который нужен прямо сейчас, чтобы будущие программисты знали, что он делает, чего не делает, и могли быстро и правильно изменить его».
вот и основная мысль рефакторинга как раз в этом — пишите код который нужен именно сейчас, не думайте о будущем. НО пишите код так чтобы его можно было с легкостью изменить в будущем под нужные требования. Если брать этот пример с факториалом, то было бы достаточно пары строк метода CalcFactorial например, а если его в будущем нужно будет расширить то например можно будет сделать поднятие/опускание метода, или выделение класса ну и тд.
System.getProperty(«com.chaosinmotion.factorialalgorithm», «cachedAlgorithm»);
Этот вызов не может вернуть null насколько я знаю.
Вообще топик- расширенное объяснение принципа KISS )
Этот вызов не может вернуть null насколько я знаю.
Вообще топик- расширенное объяснение принципа KISS )
На самом деле, всё зависит от контекста, в которой решается данная задача. Автор _почти_ прав насчёт избыточности абстракций для вычисления факториала. Но есть, как минимум, одна ситуация, в которой был бы оправдан изложенный в статье подход — если всё это часть какой-либо математической библиотеки, где вполне имеет смысл использование различных реализаций. Хотя и в этом случае, я, пожалуй, не стал бы злоупотреблять фабриками алгоритмов вычисления факториалов.
И да, не стоит бросаться в крайности. Избыточность слоёв абстракции, ровно как и полное их отсутствие — зло. Путь добра, как всегда, посередине
И да, не стоит бросаться в крайности. Избыточность слоёв абстракции, ровно как и полное их отсутствие — зло. Путь добра, как всегда, посередине
Да, именно. Кстати об этом писали и в комментах к первому переводу
habrahabr.ru/blogs/java/112969/#comment_3622601
habrahabr.ru/blogs/java/112969/#comment_3622601
По-моему, читаемость самого первого варианта кода наиболее высока. Человек, которому достанется поддерживать данный код, сразу поймет, что перед ним факториал. В случае же последнего варианта он потратит много времени на то, что бы понять что и как работает.
Вот только Ява то тут причем? :)
Этим страдают представители очень многих языков. Умение чувствовать «золотую середину» — очень ценный скилл разработчика.
Этим страдают представители очень многих языков. Умение чувствовать «золотую середину» — очень ценный скилл разработчика.
Этим страдают не языки, а некоторые разработчики с Шаблонизацией и Архитектуризацией головного мозга.
Имхо, именно в Java это сильно проявляется. Причина — существующие монструозные решения, которые пытаются создать абстракции на все и вся. Новые разработчики смотрят на все это и думают что подобный подход хорош…
Недавно была статья о логировании, там писалось об обертке поверх обертки.
Чего только стоит тот же самый Spring, в котором, отчасти и из-за плохой документации, хрен разберешься. Я как-то потратил примерно неделю (каждый вечер) в попытках разобраться как работает Spring Security и так и не смог. Я понял что мне быстрее написать свое простенькое решение, чем настраивать этого монстра.
А уж чего стоят библиотеки Java-XML маппинга — это вообще жесть.
И т.п.
Недавно была статья о логировании, там писалось об обертке поверх обертки.
Чего только стоит тот же самый Spring, в котором, отчасти и из-за плохой документации, хрен разберешься. Я как-то потратил примерно неделю (каждый вечер) в попытках разобраться как работает Spring Security и так и не смог. Я понял что мне быстрее написать свое простенькое решение, чем настраивать этого монстра.
А уж чего стоят библиотеки Java-XML маппинга — это вообще жесть.
И т.п.
Это не то чтобы проблема Java, это проблема энтерпрайза как такового. Во Flex любят городить такие же лишние абстракции. При этом самое страшное — новички считают, что это единственный абсолютно правильный метод программирования, и чем больше уровней абстракции, тем код правильнее.
Я, например, в последнее время часто бью себя по рукам, чтобы не нагородить такого барахла где не нужно.
Я, например, в последнее время часто бью себя по рукам, чтобы не нагородить такого барахла где не нужно.
1) Я не понимаю, почему в функции аппроксимации Java считается tmp2 при присваивании, когда потом он не используется.
Вот правильный код (осторожно! Си!):
static double Gamma(double z)
{
double tmp1 = sqrt(2*M_PI/z);
double tmp2 = z + 1.0/(12 * z — 1.0/(10*z));
tmp2 = pow(tmp2/M_E, z);
return tmp1 * tmp2;
}
2) Если BigInteger в Java работает подобно GMP, то имеет смысл умножать числа блоками по несколько тысяч, так не нужно постоянно растить размер буффера и на согласованных по размеру блоках быстрее работает FFT.
3) Лично я всё равно не могу придумать места, где нужно считать факториал хотя-бы тысячи.
Вот правильный код (осторожно! Си!):
static double Gamma(double z)
{
double tmp1 = sqrt(2*M_PI/z);
double tmp2 = z + 1.0/(12 * z — 1.0/(10*z));
tmp2 = pow(tmp2/M_E, z);
return tmp1 * tmp2;
}
2) Если BigInteger в Java работает подобно GMP, то имеет смысл умножать числа блоками по несколько тысяч, так не нужно постоянно растить размер буффера и на согласованных по размеру блоках быстрее работает FFT.
3) Лично я всё равно не могу придумать места, где нужно считать факториал хотя-бы тысячи.
Пишите код по сановским соглашениям, if'ы без скобок неудобно читать же.
Напомнило один анекдот,
где показывалось, как пишут код программисты в зависимости от уровня, от джуниора до босса.
сначала идет такое усложнение, до тимлида, а потом упрощение до одной строки у босса и у хакера.
где показывалось, как пишут код программисты в зависимости от уровня, от джуниора до босса.
сначала идет такое усложнение, до тимлида, а потом упрощение до одной строки у босса и у хакера.
Я понимаю, что статья о том, как «Как не надо писать %s в Java», но прежде чем писать реализацию какой-то сложной функции и делать к ней всякие ускорения в виде кэширующих классов, нужно больше узнать про эту функцию, то есть абстрагироваться от темы «Как не надо писать факториал в Java» до «Как не надо писать факториал». Дело в том, что существуют алгоритмы быстрого вычисления факториалов, они легко гуглятся (но, некоторые из тех что я нашёл вычисляют факториал не точно).
Вместо второй половины статьи можно использовать https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html (уже 9 лет как!)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как не надо писать факториал в Java