Спасибо, Дмитрий!

Thanks, Lucas!

Я имел в виду момент, когда он зашёл на английскую версию впервые т.к. это версия по умолчанию, а потом с яндекса попадал бы на русскую, но сразу редиректился на английскую, т.к. уже стояла бы кука.

Думаю, мне стоит провести исследование по тому, как пользователи себя ведут, какие сценарии повторного посещения сайта. Моё воображение почему-то рисует только плохие сценарии, вроде того, когда юзер в первый раз вбил руками refactoring.guru и закрыл страницу (записалась английская кука), все последующие его посещения, например, из яндекса будут перебрасывать его на английскую версию, что не очевидно и не желательно.

1) Я уже давно и долго над этим думал и так и не пришёл к понимаю, как это сделать для публичной части сайта так, чтобы не было ещё хуже. Набирая в браузере "refactoring.guru", вы попадаете на публичную английскую часть, т.к. она стоит по-умолчанию. Мне самому это часто не удобно, т.к. я планировал посетить русскую версию. Но мне кажется неоправданным в этом случае редиректить пользователя на русскую версию, только из-за того, что он до этого мог ходить по русской части сайта. Что касается языка аккаунта, то он равен тому языку, с которого вы логинились из публичной части. Это сделано по причине того, внезапная смена языка в аккаунте после логина тоже выглядит странно.

2) Поправил.

3) Хорошее предложение, оставил на будущее.

• страница 229    Предложение "В идеале, этот хотелось бы поместить прямо в служебный класс...". После слова "этот" пропущено слово "код". Исправил.
• страница 249    Предложение "В этом случае запрос движется по цепи, пока не найдётся обработчик, могущий его обработать.". Немного режет взгляд "могущий его обработать", я бы перефразировал, например, так: "В этом случае запрос движется по цепи, пока не найдётся обработчик, имеющий код (условия) обработки данного запроса.". Исправил.
• страница 267    Предложение "Хорошие программы обычно структурированы в виде слоёв.". Как вариант, для интересующихся можно дать ссылки на паттерны MVC/MVP MVVM... (кстати, может имеет смысл добавить их в книгу?). Это в планах на будущее.
• страница 341    Предложение "Реализуйте их так, чтобы после каждого изменения состояния они слали оповещения...". Аналогично комментарию к странице 187. Исправил.
• страница 346    Предложение "Паттерн Состояние невозможно рассматривать в отрыве от концепции машины состояний, также известной...". Ссылка "машины состояний" на английском языке, было бы логичней приводить ссылки на языке издания (в данном случае: https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BD%D0%B5%D1%87%D0%BD%D1%8B%D0%B9_%D0%B0%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82). Исправил.
• страница 359    Предложение "...все методы интерфейса состояния должны быть реализованы по всех классах состояний.". Опечатка, нужно "...реализованы ВО всех...". Исправил.
• страница 377    Предложение "В нашем примере шаги открытия и закрытия документов будут отличаться для всех подклассов, поэтому останутся абстрактными. А вот одинаковый для всех типов документов код обработки данных переедет в базовый класс.". Комментарий: если честно, не понял данный фрагмент и поэтому не согласен, на мой взгляд, "шаги открытия и закрытия документов" как раз должны быть одинаковыми, а вот "код обработки данных" как раз уникален для каждого типа документа, и поэтому всё должно быть как раз наоборот, т.е. "шаги открытия и закрытия документов" должны быть в базовом классе (с точки зрения C# данные методы можно будет сделать виртуальными, если всё же потребуется их переопределять), а вот "код обработки данных", ввиду его различия в каждой реализации, должен быть абстрактным методом с уникальной реализацией в каждом подклассе. Если что-то другое имелось ввиду, возможно нужно перефразировать, т.к. сейчас выглядит не понятно, буду рад Вашему комментарию. Я немного подправил этот момент, но в основном там имелось в виду, что для разных видов файлов могли бы понадобится различные конструкторы объектов для чтения файлов, отсюда и нужда в разных версиях методов.
• страница 378    Предложение "Это опциональные шаги, которые выглядят как обычные методы, но не содержат никакого кода.". На мой взгляд, здесь имеет смысл дополнить, чтобы не потерять нить рассуждения, начатую в конце страницы 376, например, так: "...но не содержат никакого кода (по своей сути, это абстрактные методы базового класса не требующие реализации в конкретном контексте)." Немного перефразировал это место, чтобы связь лучше просматривалась.
• страница 378    Предложение "...хук даёт подклассам дополнительные точки «вклинивания» в ход шаблонного метода.". Опечатка, нужно "...в КОД шаблонного...". Это была не опечатка, но я перефразировал, чтобы не было неоднозначности.
• страница 380    Диаграмма. Если вспомнить старую добрую Warcraft, то ресурсы как раз собирали орки, т.е. имеет смысл поменять местами заголовки производных классов на диаграмме (и кстати, раз на 381 странице Вы пишете, что "монстры вообще не будут заниматься строительством", то, также имеет смысл убрать у них на диаграмме производного класса метод "buildStructures()") ;) Эти методы присутствуют в классе монстров, т.к. их там нужно переопределить. Отсутствующие методы в классе орков значат, что они наследуют поведение родителя. Но я согласен, что это самый слабый пример из всей книги.
• страница 402    Предложение "Распечатайте шпаргалки по паттернам и...". Ссылка "шпаргалки по паттернам" на английском языке, комментарий аналогичен к странице 346. Если бы всё было так просто :) Шпаргалок на русском, к сожалению, пока ещё не существует.

Все исправления будут на сайте/в книге в течение 15 минут.

Ещё раз спасибо за то, что нашли время составить список ошибок, я очень признателен вам за это.

Thanks, Jacek!

Виправив, дякую!

Дмитрий, спасибо, что помогли с дебагом. С адболоком и включенным каналом блокировки социальных кнопок всё повторилось.

Проблему уже исправил, спасибо!

Дмитрий, спасибо за то, что нашли время расписать всё в подробностях! Таким письмам я всегда рад, т.к. уже убедился, что самостоятельно найти все ошибки в тексте просто невозможно. Далее мои комментарии будут жирным:

• страница 14     Предложение "Абстракция — это модель некоего объекта или явления реального мира, откидывающая незначительные детали...". Опечатка "откидывающая". Я сперва когда прочитал, тоже подумал, что ошибка, но потом понял, что нет, т.к. это модель откидывающая, а не явление откидывающее. В любом случае, немного перефразировал этот момент, чтобы легче читалось.

• страница 15        Предложение "...которые обычно объявляют через ключевое слово interface , можно явно описывать «контракты» взаимодействия объектов.". Да, слово "контракты" часто используется и в курсах и книгах, однако, на мой взгляд, было бы полезным, либо перед его использованием, либо сразу после, написать пару предложений об этом термине (тут конечно зависит от того, на какую аудиторию Вы рассчитываете, для новичков это будет не совсем понятно). Я действительно не хотел очень глубоко погружаться в эту тему и давать официальные определения этому термину. Я надеялся, что обознанный читатель и так всё поймёт, а незнающий воспримет это как метафору, отсюда и кавычки. Для последнего, далее по тексту идёт пример такого контракта.

• страница 43        Предложение "Но у наследования есть и проблемы, которые стают очевидными только тогда...". Опечатка "стают". Исправил.

• страница 100    Предложение "Чтобы построить стандартный дом, нужно поставить 4 стены, установить двери, вставить пару окон и постелить крышу.". Слово "постелить" режет глаза, крышу можно положить, либо крыть/покрыть, или в конце концов - поставить, а постелить можно пол, либо кровать :) Ха-ха, да, в такие моменты мне очень стыдно. Из таких моментов помню, как в самом начале один из читателей просвятил меня, что корабль и судно — это, оказывается, разные вещи. Век живи, век учись. Спасибо, исправил!

• страница 124    Предложение "Хранилище прототипов облегчает доступ к часто используемым прототипам, храня предсозданный набор...". "предсозданный" - нет такого слова в русском языке :) Исправил.

• страница 142    Предложение "Позволяет сгруппировать объекты в древовидную структуру, а затем работать с ними так, если бы это был единичный объект.". Пропущено (или так задумано?) "как" в "...работать с ними так, если бы это был...", при переходе по ссылке, слово "как" есть. Исправил.

• страница 169     Предложение "3. Определите поведения, доступные на всех платформах, и выделите из них ту часть, которая будет нужная абстракции.". Непонятное словосочетание "нужная абстракции", возможно пропущен предлог, либо неверный падеж. Исправил.

• страница 187 Предложение "Сторонняя программа должна создать и настроить этот объект, указав, кому слать оповещения...". "слать" - в данном контексте слабо применимо, слать можно гонца, а оповещения в контексте ИТ-литературы, наверное, лучше отправлять :) Исправил.

Спасибо за все исправления! Отправил обновления в деплой, через 15 минут всё будет на сайте, а также в новой версии книги.