Роберт Сесил Мартин - Чистый код. Создание, анализ и рефакторинг

выполнения» на с. 262.

(обратно)

56

См. раздел «Пример архитектуры «клиент/сервер»» на с. 357.

(обратно)

57

Также встречается термин «активная блокировка». — Примеч. перев.

(обратно)

58

http://en.wikipedia.org/wiki/Producer-consumer

(обратно)

59

http://en.wikipedia.org/wiki/Readers-writers_problem

(обратно)

60

http://en.wikipedia.org/wiki/Dining_philosophers_problem

(обратно)

61

См. раздел «Зависимости между методами могут нарушить работу многопоточного кода», с. 370.

(обратно)

62

«Критической секцией» называется любой фрагмент кода, который должен быть защищен от одновременного использования несколькими программными потоками.

(обратно)

63

См. раздел «Увеличение производительности», с. 375.

(обратно)

64

См. раздел «Взаимная блокировка», с. 377.

(обратно)

65

А вы знаете, что потоковая модель Java не гарантирует вытесняющей многопоточности? В большинстве современных ОС поддерживается вытесняющая многопоточность, которую вы фактически получаете автоматически. И все же JVM ее не гарантирует.

(обратно)

66

Строго говоря, это не совсем так. Поскольку JVM не гарантирует вытесняющей многопоточности, конкретный алгоритм может всегда работать в ОС, не поддерживающей вытеснения. Обратное тоже возможно, но по другим причинам.

(обратно)

67

http://www.alphaworks.ibm.com/tech/contest

(обратно)

68

Недавно я переписал этот модуль на Ruby. Код занимает в 7 раз меньше места и имеет более качественную структуру.

(обратно)

69

Чтобы предотвратить подобные сюрпризы в будущем, я добавил новый модульный тест, который запускал все тесты FitNesse.

(обратно)

70

JUnit Pocket Guide, Kent Beck, O’Reilly, 2004, c. 43.

(обратно)

71

См. раздел «Правило бойскаута» на с. 37.

(обратно)

72

А еще правильнее было бы считать в Javadoc все комментарии заранее отформатированными, чтобы они одинаково смотрелись в коде и в документации.

(обратно)

73

http://en.wikipedia.org/wiki/Principle_of_least_astonishment

(обратно)

74

А конкретно — принцип единой ответственности, принцип открытости/закрытости и принцип сокрытия реализаций. См. [PPP].

(обратно)

75

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

(обратно)

76

См. цитату Уорда Каннингема на с. 34.

(обратно)

77

[DDD].

(обратно)

78

Вы можете убедиться в этом сами, тестируя код до и после внесения изменений. Однопоточный код приведен на с. 385, а многопоточный – на с. 389.

(обратно)

79

Это несколько упрощенное объяснение. Впрочем, для целей нашего обсуждения мы воспользуемся этой упрощенной моделью.

(обратно)

80

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

(обратно)

81

Кто-то добавляет отладочный вывод, и проблема «исчезает». Отладочный код «решил» проблему, поэтому он остается в системе.

(обратно)

82

http://www.haifa.ibm.com/projects/verification/contest/index.html

(обратно)

83

http://www.qualitytree.com/

(обратно)
--">