Конец про класс и про методы.

Надо бы поместить про класс в предыдущий пост, но блоггер почему-то выдал ошибку, при попытке дописать в пост окончание главы. Поэтому она здесь. 

 Минимизация сложности класса:

• Включайте в класс как можно меньше методов.
• Неявно сгенерированные методы, которые не нужны, блокируйте.
• Минимизируйте число разных методов, вызываемых классом.
• Избегайте опосредованных вызовов методов из других классов.

 Несколько слов о конструкторах.
Инициализируйте по возможности все данные-члены!
Если нужен класс-одиночка - используйте синглтон.
Создавайте конструктор полного копирования, если сомневаетесь - для С++ это верно. Нужно ли это в Java, я не помню(.

Причины создания класса.

• Моделирование объектов реального мира.
• Моделирование абстрактных объектов.
• Снижение сложности.
• Изоляция сложности.
• Сокрытие деталей реализации.
• Ограничение влияния изменений.
• Упрощение передачи параметров в методы - если несколько методов используют одни и те же данные, вероятно, их нужно выделить в класс.
• Создание центральных точек управления.
• Облегчение повторного использования кода.
• Планирование создания семейства программ.
• Упаковка родственных операций.
• Выполнение специфического рода рефакторинга.

Методы.

Далее в книге идет целая глава, посвященная методам.
Причины создания методов во многом такие же, как и причины создания классов. И кроме этого, есть еще несколько:

• снижение сложности;
• формирование понятия промежуточной абстракции;
• предотвращение дублирования кода;
• поддержка наследования - т.к. переопределить небольшой грамотно спроектированный метод проще, чем длинный и плохо спроектированный;
• сокрытие очередности действий;
• сокрытие операций над указателями - неочевидная для меня причина, но очень разумная и приводящая к простоте написания программы;
• улучшение портируемости;
• упрощение сложных булевых проверок - мне раньше казалось, что наличие таких проверок - это показатель "крутости" кода, но они практически нечитаемы после написания и отладки; поэтому и с этой причиной я согласна; попытаюсь впредь делать так;
• повышение быстродействия.

Проектирование на уровне методов - проектирование методов. Методы характеризуются связностью (или силой) - соответствием выполняемых в методе операций единой цели. Самый распространенный пример хорошего метода - операция cos() или sin(). Метод cosinAndTangens() - имеет худшую связность, т.к. выполняет сразу две операции.
Цель - чтобы один метод эффективно решал одну задачу и больше ничего не делал.

Имена методов.
Имя метода должно ясно описывать все, что он делает. Т.к. ясно именовать методы в институте не учат, подробно пишу главу из книжки. Далее будет набор правил, позволяющих дать методу понятное имя. Общее правило - если метод трудно назвать, скорее всего, он плохо спроектирован.

• Описывайте все, что метод выполняет
• Избегайте невыразительных и неоднозначных глаголов
• Не используйте для различия методов исключительно номера (method1 (), method2 ()...)
• Не ограничивайте длину имени методов искусственными правилами - имя метода длиннее имени переменной; главной задачей имени является ясное и понятное описание сути метода.
• Для именования функции используйте описание возвращаемого значения.
• Для именования процедуры используйте выразительный глагол ( дополняя его объектом, если язык не ОО).
• Определяйте конвенции именования часто используемых операций.
• Дисциплинированно используйте антонимы. Т.к. это тоже одно из моих больных мест, пишу здесь часто используемые:

add/remove
begin/end
create/destroy
first/last
get/put
get/set
increment/decrement
insert/delete
lock/unlock
min/max
next/previous
old/new
open/close
show/hide
sourse/target
start/stop
up/down

Желательно, чтобы длина метода была не более 150-200 строк(без комментариев и пустот), обычно метод занимает до 100 строк. Если метод хорошо спроектирован, он уложится в эти рамки (должен).

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

Про макросы. 
Опять же, программируя на С++ я думала, что использовать макросы - это показатель крутости. Но их использование давало иногда такие ошибищи которые очень трудно было отследить и понять.  Макконнелл не рекомендует использовать макросы, кроме как в условной компиляции (он ссылается в этом на Страуструпа, а тот, видимо, знает, что говорит)).

Итак, ура. Глава, посвященная методам обработана. Надеюсь, я буду это все использовать. Очень часто при чтении этой книги у меня возникают мысли: а, как просто-то, а я... Учиться мне еще и учиться...