Не знаю как более новые версии, но в 10.10 приходится долго натягивать CSS для достижения нужного эффекта. Хотя вроде бы все по стандарту.
Firefox и IE все-таки более предсказуемы (не смотря на все известные баги, IE все-таки становится более предсказуем).
Проще всего было бы сделать число потоков пропорциональным 2^n.
Тогда можно просто остатком от деления получить номер текущего потока.
А на ноль в это мслучае сбрасывать не надо, т.к. при превышении MAX_VALUE получишь такое же отрицательное число.
Резюмируя, получаем примерно так:
public int getNextId() {
int currentPosition = position.getAndIncrement();
if (currentPosition < 0) {
currentPosition += Integer.MAX_VALUE; // Integer.MAX_VALUE == 2^31 - 1
currentPosition++; // Сделаем кратным 2^31
assert (currentPosition > 0); // Нет переполнения
}
return objectList.get(currentPosition % objectList.size());
}
Согласен. В каждой существующей парадигме программирования на данный момент есть свои плюсы. Если их правильно объединить (читать: удобно, гибко, естественно и т.д.), получится мощное средство разработки.
Я лично когда начинаю писать какой-либо более-мелее отделенный от остальной системы функционал, всегда вначале создаю несколько интерфейсов, с которыми клиент этой части системы может работать. После этого тесты на этот интерфейс напрашиваются сами.
Это хорошо работает для обособенной логики. Если же нужно протестить Web, EJB и т.д., то используем мощь соответствующего framework'а. Как правило, сейчас даже в мануалах есть разделы «как это тестировать».
Иногда появляются утилитные бизнес-методы этак на 2-7 строчек, и их не привяжешь к какому-либо объекту, т.к. это будет противоречить принципам ООП.
Вот и выделяются в static-методы утилитных классов. Их, конечно, можно пихать в DI, но делать из утилитного класса singleton только для пропихивания logger'а — ИМХО, некрасиво.
А насчет AOP… Ну, не все используют AOP. Из разных соображвений, но иногда полномочий не хватает, чтобы внедрить технологию, приходится использовать то, что есть, с полной отдачей.
Тут просто ) Достаточно включить логику.
Сам посуди: когда ты пишешь код a =…, ожидается, что все, что написано справа, присвоится переменной a. Следовательно, присваивание всегда идет последним. А, стало быть, присвоить что-либо выражению нельзя, т.к. это не L-value.
Другая парадигма -> другой тип мышления.
LISP нужно попробовать с его сильных сторон, и после этого понимаешь, как им пользоваться и какие преимущества получаются в итоге.
В данном случае это все-таки не реальная, а академическая задача. Как раз для случаев, когда нужно проверить, насколько у разработчика работают мозги. В реальной жизни оно вряд ли встретится при нормальном подходе к программированию (объект-оболочка + запоминание длины списка).
Впринципе полезная вещь.
Больше не люблю, т.к. предпочитаю, чтобы все было на виду.
Firefox и IE все-таки более предсказуемы (не смотря на все известные баги, IE все-таки становится более предсказуем).
Тогда можно просто остатком от деления получить номер текущего потока.
А на ноль в это мслучае сбрасывать не надо, т.к. при превышении MAX_VALUE получишь такое же отрицательное число.
Резюмируя, получаем примерно так:
Я лично когда начинаю писать какой-либо более-мелее отделенный от остальной системы функционал, всегда вначале создаю несколько интерфейсов, с которыми клиент этой части системы может работать. После этого тесты на этот интерфейс напрашиваются сами.
Это хорошо работает для обособенной логики. Если же нужно протестить Web, EJB и т.д., то используем мощь соответствующего framework'а. Как правило, сейчас даже в мануалах есть разделы «как это тестировать».
В данном случае можно научиться пошаговому рефакторингу из самых ужасных ситуаций.
Иногда появляются утилитные бизнес-методы этак на 2-7 строчек, и их не привяжешь к какому-либо объекту, т.к. это будет противоречить принципам ООП.
Вот и выделяются в static-методы утилитных классов. Их, конечно, можно пихать в DI, но делать из утилитного класса singleton только для пропихивания logger'а — ИМХО, некрасиво.
А насчет AOP… Ну, не все используют AOP. Из разных соображвений, но иногда полномочий не хватает, чтобы внедрить технологию, приходится использовать то, что есть, с полной отдачей.
Сам посуди: когда ты пишешь код a =…, ожидается, что все, что написано справа, присвоится переменной a. Следовательно, присваивание всегда идет последним. А, стало быть, присвоить что-либо выражению нельзя, т.к. это не L-value.
Надо еще раз исходники основный классов Java полистать )
LISP нужно попробовать с его сильных сторон, и после этого понимаешь, как им пользоваться и какие преимущества получаются в итоге.
Из Arrays.add() ведь нельзя изменить ссылку )