----------------------------
Глава 2.
стр. 54
"В этой главе мы перейдем на качественно новый уровень программирования -- наши программы будут содержать несколько классов. "
Слова "качественно новый уровень" коробят. Можно просто "новый уровень" ?
стр. 55
Идея листинга не описана. Т.е. она будет понятна, только во время прочтения исходного кода, благо он занимает 18 строк вместе с комментариями.
стр. 59
"Вкратце сюжет пьесы такой"
Перефразировать.
стр. 60
"Перегрузка методов -- весьма полезный и перспективный механизм, который позволяет создавать очень гибкие и эффективные методы.
В общих чертах суть перегрузки методов состоит в том, что в классе можно создавать (описывать) несколько вариантов одного и того же метода. "Несколько вариантов" в данном случае означает, что все эти методы имеют одинаковые названия, но при этом различаются количеством и (или) типом аргументов"
Достаточно сложный для понимания обзац. Хотелось бы перефразировать.
Примечание, кстати, дает более понятное объяснение.
стр. 64
"По сравнению с конструкторами, деструкторы используются не так часто, но не менее эффектно."
Эффектно или эфективно?
"Все дело в том, что команда создания объекта выглядит на самом деле как new конструктор_класса(аргументы)."
на самом деле как - лишние слова
Все дело в том - так же можно пропустить.
стр. 65
Листинг программы безидейный.
"Мы создаем Windows-проект, со всеми вытекающими отсюда последствиями".
стр. 68
"При этом новый объект на самом деле совсем не объязательно должен быть копией исходного объекта (...)"
на самом деле совсем - это лишние слова.
стр. 73
Внимание! (Про доступ к закрытым private полям)
"[описание]. Вот такой вот парадокс (который, разумеется, на самом деле пардоксом не является)"
Во первых парадокса здесь нет по определению. Это стандартная вещь в ООП.
Если говорить что это мнимый парадокс, это только запутает читателя, который только только разобрался с "видимостью" полей.
И разумеется, на самом деле - здесь есть лишние слова.
стр. 83 +
Идея листинга описана сразу же после листинга. Это хорошо.
----------------------------
Глава 3.
стр. 109
Первая блок-схема в книге.
Выполняются не командЫ, а командА.
Еще верней - оператор. А {} - это составной оператор.
Но оператор_ - один.
Кстати об этом указано на стр. 110 в примечании. "Если блок команд в условном операторе состоит всего из одной инструкции, в фигурные скобки такой блок можно не заключать."
Все равно я считаю, что необходимо вводить понятие "составной оператор", чтобы не морочить голову различными исключениями. (цикл for () стр. 114 п.3 "Если тело цикла состоит из одной команды, фигурные скобки можно не использовать")
стр. 110
Условие пишется в ромбе, а не в прямоугольнике.
Значения true, false подписываются, а не рисуются в ромбах.
Выполняется команда. (см. выше)
Если про какие-то моменты можно поспорить, то то, что схемы на развороте (110-111) не согласованы, видно сразу.
"Еще один оператор, который нередко относят к группе условных операторов, -- оператор switch(). Основное рабочее название этого оператора -- оператор выбора."
Предложения перефразировать, объеденить в одно.
стр. 111
"На рис. 3.3 показана схема выполнения оператора выбора в картинках."
Масло маслянное.
"В словах последовательность выполнения оператора выбора может быть описана следующим образом."
Здесь точно запятые не нужны?
"Если совпадение найдено, выполняются команды соответствующего case-блока."
Если ... , то ...
Предложение
"Как выполняется оператор выбора без default-блока, иллюстриурет диаграмма на рис. 3.4."
можно вычеркнуть, а ссылку прикрепить к следующему предложению:
"Если в операторе выбора блока по умолчанию нет, то при отсутствии совпадений управление передается следующему после оператора выбора оператору."
Комментировать предложение не буду.
стр. 112
"Рис. 3.4. Схема выполнения оператора выбора без default-блока."
Схема или диаграмма? (см стр. 111)
Внимание. "... инструкцией break."
инструкцией безусловного перехода, которая служит для перкращения анализа условия, выполнения команд условного оператора и перехода к следующим операциям программы.
стр. 113
Цикл While.
Те же ошибки в блок-схеме.
Тот же составной оператор.
"Последоавтельность действий проиллюстрирована диаграммой на рис. 3.5"
Рис. 3.5. Схема выполнения оператора цикла while()
"... структурной диаграмме на рис. 3.6." не соотв. стр. 114 "Рис. 3.6. Схема выполнения ... "
стр. 115
"Если условие равно true"
Если логический результат вычисления условия равен true
"Для удобства и разрешеняи неоднозначных ситуаций линии, определяющиеполследовательность выполнения блоков, экипированы стрелками."
Во первых есть ГОСТ для оформления блок схем. Во вторых что значит "экипированы"?
Сама блок-схема -- "Я умею рисовать различные схемы в Word!" ?
"Даже из изложенного выше становится совершенно очевидно, что оператор цикла for() допускает огромное количество способов вызова."
Гениальная фраза! Из некой не совсем понятной схемы, сбивчивого объяснения, вдруг (неожиданно!) любому карапузу становится совершенно очевидно, что мегасложный оператор цикла for() имеет практически неисчислимое количество самых разнообразных способов вызова этого замечательнейшего оператора! Ну право, чего мелочиться то?
стр. 115-116
Многострадальному оператору goto посвящено целых 13 строк!
стр. 116-121
Я книгу читаю последовательно! Для себя подписывал окончания useWhile, useFor (названия процедур) к закрывающим фигурным скобкам.
"for (;i<n
{"
предупреждать о такой конструкции надо. Т.к. приходится листать книгу взад/вперед, чтобы понять, не ошибся ли автор?
"for (i=1, s=0; i<=n; s+=i++);"
Хитро. Строго говоря так не делают, это удобство.
стр. 122
"В теле оператора цикла командой i++ ... " до окнца обзаца.
Это чисто повезло. К вычислению суммы натуральных чисел, это относится лишь как частный случай.
стр. 123
"... метод useGoto(), в котором ... , стоит некоторым особняком, хотя на самом деле ничего особенного в этом методе нет."
на самом деле - лишние слова.
"... помечен скромной инстуркцией start, которая является не чем иным, как меткой."
не чем иным - лишние слова.
стр. 124
"... сводится к смене симольного значения переменноц на следующую букву в кодовой странице символов."
Термин "кодовая страница символов" введен впервые. Очень хотелось бы видеть вырезку с информацией об этом.
стр. 125
Массивы большие и маденькие.
Первый абзац. Я даже переписывать и комментировать его не хочу. Переписать полностью.
"тип элементов массива -- нужно знать, сколько памяти отводить под каждый из элементов массива;"
Расстроен, не удеружусь, спрошу. Кому нужно знать?
стр. 126
Примечание
"переменная, в которой записанная ссылка на реальный массив."
называется "указатель".
стр. 127
"При объявлении переменной многомерного массива после имени типа элементов массива в квадратных скобках указываются запятые (количество запятых -- размерность массива минус один);"
1) Точно тут запятых нет?
2) Я впервые вижу, чтобы размерность массива определяли по такой формуле!
стр. 131
"Мы, ничтоже сумняшеся, командой Random ... "
Вообще на странице хотелось бы видеть более явное разделение процедуры получения псевдослучайного числа и процедуры приведения типов.
стр. 132
"Актуальна задача быстрой и простой инициализации массива. Такая метода есть."
Такая методика есть.
стр. 133
"Как уже отмечалось, при работе с массивам инередко используется оператор цикла foreach()."
Упоминалось этак вскользь в примечании на стр. 116
"Другими словами, на каждом цикле значение переменной s ..."
Другими словами, в каждой итерации цикла значение переменной s ...
стр. 136
Совет.
Нет ни одного слова про радианы.
стр. 138
Про заполнение массива binom[i] описать словами или формулой. Но не командами C#.
стр. 140
Примечание.
Указатели C#, это не отголосок, это наследие от С++. Кроме того, отсутствие ссылок в Java явлеется следствием того, что Java выполняется на виртуальной машине JVM и не может напрямую работать с памятью. см. примечание на стр. 141 "Дело в том, что через указатели мы получаем доступ к операциям с памятью. Исполнительная система не может гарантировать полную безопасность программного кода с указателями."
стр. 141
"..., используем инструкцию вида double* q, ..."
q - ранее не определена. Придирка.
стр. 142
"... разберем поэтапно команды в методе Main()..."
поэтапно -- странное слово
"В результат адрес, по которому прописана переменная n, ..."
В результат -> В результате -- ошибка.
"То, что мы увидели, -- это только вершина айсберга."
Пунктуация верна?
----------------------------
Глава 4.
Первый абзац переформулировать полностью!
стр. 144
Прилирка.
"А истина, как известно, всегда находится где-то посредине между наиболее радикальными вариантами."
Чего? предложение не понятно.
"Поэтому задача перегрузки оператора ... к объекту класса. Другими словами ..."
В первом предлложении многа букаф. Желательно вычеркнуть.
Перечисление.
Придирка
п. 1. "... атрибуты public и static ... " Наконец то дошло до объяснения ключевого слова static ?
"В листинге 4.1 приведен программный код простенькой программы, в которой использована перегрузка некоторых операторов -- а если быть более точным, то двух."
Уточнение не к месту.
стр. 145
Примечание.
(Программа пересчета курса валют + простейшие операции денежных переводов)
"Прежде чем приступить к анализу программного кода, имеет смысл кратко остановиться на общей идее. А идея в том, чтобы ..."
Мегареспект! Наконец то! Наконецто появилась вербальная модель задачи, вперед программы.
Транши -- это термин из другой области.
http://ru.wikipedia.org/wiki/Транш
Он вообще к программе отношения не имеет! Акуратнее пожалуйста в терминологии.
"У класса есть два поля: одно содержит... , а еще одно поле содержит ..."
"а еще одно поле" -> "другое поле"
"Мы будем пользоваться следующим правилом. ..."
Далее все вычекнуть, а оставить нормальные и понятные формулы.
Или переформулировать.
Листинг 4.1
Работа программы не понятна, не прозрачна и вызывает множество вопросов.
Как по своей логике, так и по реализации.
Перегрузка унарного оператора ! смысла не имеет.
Dol -> Dollar
Eur -> Euro
стр. 149
" Командой A.show() отображается информация об объекте-операнде, а командой return A.price() в качестве результата метода возвращается "рублевая цена" операнда. "
Пунктуация верна?
стр. 150
Результат работы программы.
Откуда взялось значение 500 ?
стр. 151
"Но, перед анализом программного кода, по сложившейся традиции -- несколько слов об общей идее, положенной в основу программного кода."
Ойййй!
Примечание.
Фраза о соотношении кол-ва читателей и кол-ва формул не принадлежит Стивену Хокингу.
стр. 152
aracsin не соотв. стр. 154 Math.Acos
не соответствует описанию "... на косинус угла между ними, ..."
(речь идет про вычисление скалярного произведения векторов через угол)
Насколько корректна фраза
"Обратимся к программному коду в листинге 4.2." ?
стр. 152-156
Листинг
Опять же напоминаю, я, как и любой здравомысляший человек, книгу читаю в порядке изложения.
public static double operator / (Vector a, Vector b) {}
Такая операция не допустима!
По результатам на возвращается угол Фи
"return phi;"
Только на стр. 157 дается пояснение.
"Кроме этого, можно будет делить вектор на числа, а также формально делить вектор на вектор. В последнем случае вы проявили инициативу -- в математике такая операция недопустима".
Вводятся два новых термина explict и implict, ранее нигде явно не указанные и не объясненные.
public static explict operator double(Vector a){
public static implict operator string(Vector a){
стр. 157
"Культурологическим шоком может стать перегрузка операторов приведения типа(или преобразования типа)."
Когнитивный диссонанс?
стр. 158
"Описывается метод как Vector ... "
слова "Описывается метод" хочется поменять местами или перефразировать.
стр. 159
"... вычисляется по военному просто ..."
по военному просто - лишние слова.
Только за 4 строки до конца таблицы разъясняется ключевое слово explict - перегрузка оператора явного приведения типа.
стр. 160
Из примечания не ясно, что есть явное и неявное приведение типов.
Даже не смотря на запутанный пример. Про Дримз кам тру! Молчу.
В самом конце примечания, дано краткое разъяснение implict - оператор неявного преобразования описывается с атрибутов implict вместо explict.
"С таким оператором мы еще столкнемся."
Этот случай не в счет?
стр. 162
Наконец то дано грамотное объяснение неявному приведению типов.
Знак равенства и знак тождества -- это разные вещи!
стр. 164
"необходимо переопределить методы Object.Equals() и Object.GetHashCode()."
Как то вдруг внезапно. Благо что во врезке "Внимание!"
"Но операции сравнения больше/меньше не имеют особого математического смысла. Мы устраним эту досадную оплошность."
Чего мы сделаем???
стр. 166
Листинг стр. 165-168 -- работа с комплексными числами
выражение
" else return a.Re+((a.Im<0)?"":")+a.Im+"i"; "
абсолютно понятно любому школьнику!
стр. 168
Внимание!
"Поэтому, например, действительное число -- это частный случай комплексного числа, у кторого мнимая часть равна нулю."
Поэтому, например, -- лишние слова.
стр. 170
Первая строка.
"Если число не является действительным, (то) нам нужно проверить ..."
частицы "то" не хватает.
