Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 37

НЛО прилетело и опубликовало эту надпись здесь
Молодец, не расстраивайтесь.
Я сам из другого лагеря ( C# ), эту статью читал в первый раз.
Спасибо! Статья и перевод понравились.

Всего голосов 7: ↑6 и ↓1+5
НЛО прилетело и опубликовало эту надпись здесь
Опа, Вы правы, я не понял.
Всего голосов 1: ↑1 и ↓0+1
Опа!
В том переводе пропущена большая и самая важная часть!
Всего голосов 7: ↑6 и ↓1+5
Значит остальное можно убрать и поставить ссылку на тот топик.
Всего голосов 8: ↑4 и ↓40
Возможно я тормоз, но странный у вас синглтон получился. В смысле ничто не мешает несколько экземпляров класса FactorialUtil получить, как с одинаковыми, так и с разными алгоритмами, какой же это синглтон?
Всего голосов 2: ↑0 и ↓2-2
William Woody вряд ли зайдет на Хабр ответить на комментарии, так что и обращаться к нему бессмысленно.
Всего голосов 2: ↑2 и ↓0+2
Кто-нибудь, вышлите Вильяму Вуди инвайт
Всего голосов 5: ↑4 и ↓1+3
А я думал переводчик переводит комментарии и форвардит их в блог с оригинальной статьей (чешу репу, предварительно сделав глупое выражение лица).
Комментарий пока не оценивали0
Объявляется неделя факториала!
Всего голосов 5: ↑4 и ↓1+3
прирост +10 существ!
Всего голосов 5: ↑5 и ↓0+5
прирост +10 алгоритмов и решений :)

Но концовочка в этом переводе действительно ценная.
Всего голосов 1: ↑1 и ↓0+1
НЛО прилетело и опубликовало эту надпись здесь
В главе 24 книги «Совершенный код» С. Макконнелл говорит: «Мнение экспертов по этому поводу [программа содержит код, который может когда-нибудь понадобиться] однозначно: если вы хотите наилучшим образом подготовиться к будущим требованиям, не пишите гипотетически нужный код, а уделите повышенное внимание ясности и понятности кода, который нужен прямо сейчас, чтобы будущие программисты знали, что он делает, чего не делает, и могли быстро и правильно изменить его».
Всего голосов 6: ↑6 и ↓0+6
вот и основная мысль рефакторинга как раз в этом — пишите код который нужен именно сейчас, не думайте о будущем. НО пишите код так чтобы его можно было с легкостью изменить в будущем под нужные требования. Если брать этот пример с факториалом, то было бы достаточно пары строк метода CalcFactorial например, а если его в будущем нужно будет расширить то например можно будет сделать поднятие/опускание метода, или выделение класса ну и тд.
Комментарий пока не оценивали0
Собственно, это и есть глава «Рефакторинг» :)
Комментарий пока не оценивали0
у макконелла рефакторинг сжатенько написан. Лучше прочитать фаулера. Там более подробно
Всего голосов 1: ↑1 и ↓0+1
System.getProperty(«com.chaosinmotion.factorialalgorithm», «cachedAlgorithm»);
Этот вызов не может вернуть null насколько я знаю.

Вообще топик- расширенное объяснение принципа KISS )
Комментарий пока не оценивали0
На самом деле, всё зависит от контекста, в которой решается данная задача. Автор _почти_ прав насчёт избыточности абстракций для вычисления факториала. Но есть, как минимум, одна ситуация, в которой был бы оправдан изложенный в статье подход — если всё это часть какой-либо математической библиотеки, где вполне имеет смысл использование различных реализаций. Хотя и в этом случае, я, пожалуй, не стал бы злоупотреблять фабриками алгоритмов вычисления факториалов.
И да, не стоит бросаться в крайности. Избыточность слоёв абстракции, ровно как и полное их отсутствие — зло. Путь добра, как всегда, посередине
Всего голосов 4: ↑4 и ↓0+4
По-моему, читаемость самого первого варианта кода наиболее высока. Человек, которому достанется поддерживать данный код, сразу поймет, что перед ним факториал. В случае же последнего варианта он потратит много времени на то, что бы понять что и как работает.
Всего голосов 1: ↑0 и ↓1-1
При наличии комментариев — думаю проблем быть не должно. Вопрос в другом — нужно ли когда-то в принципе подменять имплементацию мат функции в рантайме? Решение о пределах, времени выполнения зависит от алгоритма, где конкретная функция используется
Комментарий пока не оценивали0
Вот только Ява то тут причем? :)
Этим страдают представители очень многих языков. Умение чувствовать «золотую середину» — очень ценный скилл разработчика.
Всего голосов 2: ↑0 и ↓2-2
Этим страдают не языки, а некоторые разработчики с Шаблонизацией и Архитектуризацией головного мозга.
Всего голосов 4: ↑2 и ↓20
Угу… недавно на Хабре проскакивало: «пахлава-код» :)
Всего голосов 1: ↑1 и ↓0+1
Мне по этому поводу больше понравилась фраза «ООПухоль мозга», тоже недавно встретил на Хабре :)
Всего голосов 2: ↑2 и ↓0+2
Имхо, именно в Java это сильно проявляется. Причина — существующие монструозные решения, которые пытаются создать абстракции на все и вся. Новые разработчики смотрят на все это и думают что подобный подход хорош…

Недавно была статья о логировании, там писалось об обертке поверх обертки.
Чего только стоит тот же самый Spring, в котором, отчасти и из-за плохой документации, хрен разберешься. Я как-то потратил примерно неделю (каждый вечер) в попытках разобраться как работает Spring Security и так и не смог. Я понял что мне быстрее написать свое простенькое решение, чем настраивать этого монстра.
А уж чего стоят библиотеки Java-XML маппинга — это вообще жесть.
И т.п.
Всего голосов 1: ↑1 и ↓0+1
Это не то чтобы проблема Java, это проблема энтерпрайза как такового. Во Flex любят городить такие же лишние абстракции. При этом самое страшное — новички считают, что это единственный абсолютно правильный метод программирования, и чем больше уровней абстракции, тем код правильнее.

Я, например, в последнее время часто бью себя по рукам, чтобы не нагородить такого барахла где не нужно.
Всего голосов 2: ↑2 и ↓0+2
НЛО прилетело и опубликовало эту надпись здесь
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) Лично я всё равно не могу придумать места, где нужно считать факториал хотя-бы тысячи.
Комментарий пока не оценивали0
Пишите код по сановским соглашениям, if'ы без скобок неудобно читать же.
Всего голосов 2: ↑1 и ↓10
Напомнило один анекдот,
где показывалось, как пишут код программисты в зависимости от уровня, от джуниора до босса.
сначала идет такое усложнение, до тимлида, а потом упрощение до одной строки у босса и у хакера.
Всего голосов 2: ↑2 и ↓0+2
Я понимаю, что статья о том, как «Как не надо писать %s в Java», но прежде чем писать реализацию какой-то сложной функции и делать к ней всякие ускорения в виде кэширующих классов, нужно больше узнать про эту функцию, то есть абстрагироваться от темы «Как не надо писать факториал в Java» до «Как не надо писать факториал». Дело в том, что существуют алгоритмы быстрого вычисления факториалов, они легко гуглятся (но, некоторые из тех что я нашёл вычисляют факториал не точно).
Комментарий пока не оценивали0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr