17. Понятие связности класса. Влияние связности на размер классов.

СВЯЗНОСТЬ

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

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

Стратегия компактных функций и коротких списков параметров иногда приво­дит к росту переменных экземпляров, используемых подмножеством методов. Это почти всегда свидетельствует о том, что по крайней мере один класс пыта­ется выделиться из более крупного класса.

ПОДДЕРЖАНИЕ СВЯЗНОСТИ ПРИВОДИТ К УМЕНЬШЕНИЮ КЛАССОВ

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

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

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

В результате строение программы улучшается, а ее структура становится более прозрачной.

18. Структурирование класса с учетом его изменений. Принципы проектирования классов в ооп.

СТРУКТУРИРОВАНИЕ С УЧЕТОМ ИЗМЕНЕНИЙ

Большинство систем находится в процессе непрерывных изменений. Каждое из­менение создает риск того, что остальные части системы будут работать не так, как мы ожидаем. В чистой системе классы организованы таким образом, чтобы риск от изменений был сведен к минимуму

Код каждого класса становится до смешного простым. Время, необходимое для понимания класса, падает почти до нуля. Вероятность того, что одна из функций нарушит работу другой, ничтожно мала. С точки зрения тестирования проверка всех фрагментов логики в этом решении упрощается, поскольку все классы изо­лированы друг от друга.

Что не менее важно, когда придет время добавления update, вам не придется из­менять ни один из существующих классов!

Принцип проектирования классов в ООП, называемый принципом открытости/ закрытости [РРР]: классы должны быть открыты для расширений, но закрыты для модификации.

Структура системы должна быть такой, чтобы обновление системы (с добав­лением новых или изменением существующих аспектов) создавало как можно меньше проблем. В идеале новая функциональность должна реализовываться расширением системы, а не внесением изменений в существующий код.