- 🐻 Русский / Russian
-
Помилки
0
Виправлено
книга про паттерны (некоторые моменты)
Александр, добрый день,
читаю Вашу книгу про паттерны, подача материала и структура книги мне нравится, однако хочу поделиться с Вами своим взглядом на некоторые моменты, которые бросились в глаза (прошу не считать критикой, учитывать/не учитывать, полностью на Ваше усмотрение :) Всё написанное ниже относится к редакции книги v2018-2.10):
- страница 14 Предложение "Абстракция — это модель некоего объекта или явления реального мира, откидывающая незначительные детали...". Опечатка "откидывающая".
- страница 15 Предложение "...которые обычно объявляют через ключевое слово interface , можно явно описывать «контракты» взаимодействия объектов.". Да, слово "контракты" часто используется и в курсах и книгах, однако, на мой взгляд, было бы полезным, либо перед его использованием, либо сразу после, написать пару предложений об этом термине (тут конечно зависит от того, на какую аудиторию Вы рассчитываете, для новичков это будет не совсем понятно).
- страница 43 Предложение "Но у наследования есть и проблемы, которые стают очевидными только тогда...". Опечатка "стают".
- страница 100 Предложение "Чтобы построить стандартный дом, нужно поставить 4 стены, установить двери, вставить пару окон и постелить крышу.". Слово "постелить" режет глаза, крышу можно положить, либо крыть/покрыть, или в конце концов - поставить, а постелить можно пол, либо кровать :)
- страница 124 Предложение "Хранилище прототипов облегчает доступ к часто используемым прототипам, храня предсозданный набор...". "предсозданный" - нет такого слова в русском языке :)
- страница 142 Предложение "Позволяет сгруппировать объекты в древовидную структуру, а затем работать с ними так, если бы это был единичный объект.". Пропущено (или так задумано?) "как" в "...работать с ними так, если бы это был...", при переходе по ссылке, слово "как" есть.
- страница 169 Предложение "3. Определите поведения, доступные на всех платформах, и выделите из них ту часть, которая будет нужная абстракции.". Непонятное словосочетание "нужная абстракции", возможно пропущен предлог, либо неверный падеж.
- страница 187 Предложение "Сторонняя программа должна создать и настроить этот объект, указав, кому слать оповещения...". "слать" - в данном контексте слабо применимо, слать можно гонца, а оповещения в контексте ИТ-литературы, наверное, лучше отправлять :)
Пока дочитал до 200-й страницы, если встречу что-то еще, дополню в данной теме.
Спасибо за Ваш труд.
С уважением,
Дмитрий
Відповідь
Відповідь
Виправлено
Дмитрий, спасибо за то, что нашли время расписать всё в подробностях! Таким письмам я всегда рад, т.к. уже убедился, что самостоятельно найти все ошибки в тексте просто невозможно. Далее мои комментарии будут жирным:
- страница 14 Предложение "Абстракция — это модель некоего объекта или явления реального мира, откидывающая незначительные детали...". Опечатка "откидывающая". Я сперва когда прочитал, тоже подумал, что ошибка, но потом понял, что нет, т.к. это модель откидывающая, а не явление откидывающее. В любом случае, немного перефразировал этот момент, чтобы легче читалось.
- страница 15 Предложение "...которые обычно объявляют через ключевое слово interface , можно явно описывать «контракты» взаимодействия объектов.". Да, слово "контракты" часто используется и в курсах и книгах, однако, на мой взгляд, было бы полезным, либо перед его использованием, либо сразу после, написать пару предложений об этом термине (тут конечно зависит от того, на какую аудиторию Вы рассчитываете, для новичков это будет не совсем понятно). Я действительно не хотел очень глубоко погружаться в эту тему и давать официальные определения этому термину. Я надеялся, что обознанный читатель и так всё поймёт, а незнающий воспримет это как метафору, отсюда и кавычки. Для последнего, далее по тексту идёт пример такого контракта.
- страница 43 Предложение "Но у наследования есть и проблемы, которые стают очевидными только тогда...". Опечатка "стают". Исправил.
- страница 100 Предложение "Чтобы построить стандартный дом, нужно поставить 4 стены, установить двери, вставить пару окон и постелить крышу.". Слово "постелить" режет глаза, крышу можно положить, либо крыть/покрыть, или в конце концов - поставить, а постелить можно пол, либо кровать :) Ха-ха, да, в такие моменты мне очень стыдно. Из таких моментов помню, как в самом начале один из читателей просвятил меня, что корабль и судно — это, оказывается, разные вещи. Век живи, век учись. Спасибо, исправил!
- страница 124 Предложение "Хранилище прототипов облегчает доступ к часто используемым прототипам, храня предсозданный набор...". "предсозданный" - нет такого слова в русском языке :) Исправил.
- страница 142 Предложение "Позволяет сгруппировать объекты в древовидную структуру, а затем работать с ними так, если бы это был единичный объект.". Пропущено (или так задумано?) "как" в "...работать с ними так, если бы это был...", при переходе по ссылке, слово "как" есть. Исправил.
- страница 169 Предложение "3. Определите поведения, доступные на всех платформах, и выделите из них ту часть, которая будет нужная абстракции.". Непонятное словосочетание "нужная абстракции", возможно пропущен предлог, либо неверный падеж. Исправил.
- страница 187 Предложение "Сторонняя программа должна создать и настроить этот объект, указав, кому слать оповещения...". "слать" - в данном контексте слабо применимо, слать можно гонца, а оповещения в контексте ИТ-литературы, наверное, лучше отправлять :) Исправил.
Спасибо за все исправления! Отправил обновления в деплой, через 15 минут всё будет на сайте, а также в новой версии книги.
Александр, добрый день,
спасибо за оперативность, подтверждаю исправления, дальнейшие комментарии относятся к версии книги v2018-2.11:
- страница 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.
С уважением,
Дмитрий
- страница 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 минут.
Ещё раз спасибо за то, что нашли время составить список ошибок, я очень признателен вам за это.
Александр,
был рад помочь, спасибо за проделанную работу, купил рекомендованную Вами книгу (кстати, советую обновить ссылку на 402- странице, т.к. сейчас есть обновленная версия данной книги: http://shtonda.blogspot.com/2016/04/refactoring-patterns-joshua-kerievsky.html).
С уважением,
Дмитрий
Служба підтримки клієнтів працює на UserEcho
Дмитрий, спасибо за то, что нашли время расписать всё в подробностях! Таким письмам я всегда рад, т.к. уже убедился, что самостоятельно найти все ошибки в тексте просто невозможно. Далее мои комментарии будут жирным:
Спасибо за все исправления! Отправил обновления в деплой, через 15 минут всё будет на сайте, а также в новой версии книги.