 |
Закон Деметры. Опасность построения гибридов объектов и структур данных. Объекты передачи данных и активные записи
|
|
|
|
Вопрос 12
Закон Деметры. Опасность построения гибридов объектов и структур данных. Объекты передачи данных и активные записи
Закон Деметры
Модуль не должен знать внутреннее устройство тех объектов, с которыми он работает. Объекты скрывают свои данные и предоставляют операции для работы с ними. Это означает, что объект не должен раскрывать свою внутреннюю структуру через методы доступа, потому что внутреннюю структуру следует скрывать. Метод не должен вызывать методы объектов, возвращаемых любыми из разрешенных функций.
Гибриды
Вся эта неразбериха иногда приводит к появлению гибридных структур — наполовину объектов, наполовину структур данных. Гибриды содержат как функции для выполнения важных операций, так и открытые переменные или открытые методы чтения/записи, которые во всех отношениях делают приватные переменные открытыми. Другим внешним функциям предлагается использовать эти переменные так, как в процедурных программах используются структуры данных.
Подобные гибриды усложняют как добавление новых функций, так и новых структур данных. Они объединяют все худшее из обеих категорий.
Вопрос 16
Класс. Размеры класса. Принцип единой ответственности (SRP)
По стандартным правилам класс должен начинаться со списка переменных. Сначала перечисляются открытые статические константы. Далее следуют приватные статические переменные, а за ними идут приватные переменные экземпляров. За списком переменных обычно следуют открытые функции. Такое размещение соответствует правилу понижения, в результате чего программа читается как газетная статья.
|
|
|
Первое правило: классы должны быть компактными. Второе правило: классы должны быть еще компактнее.
В классах используется другая метрика; мы подсчитываем ответственности [RDD].
Имя класса должно описывать его ответственности. В сущности, имя должно стать первым фактором, способствующим определению размера класса. Если для класса не удается подобрать четкое, короткое имя, вероятно, он слишком велик. Чем туманнее имя класса, тем больше вероятность, что он имеет слишком много ответственностей.
Краткое описание класса должно укладываться примерно в 25 слов, без выражений «если», «и», «или» и «но
Принцип единой ответственности (SRP)
Принцип единой ответственности (SRP1) утверждает, что класс или модуль должен иметь одну — и только одну — причину для изменения.
Этот принцип дает нам как определение ответственности, так и критерий для оценки размера класса. Классы должны иметь одну ответственность, то есть одну причину для изменений.
Попытки идентификации ответственностей (причин для изменения) часто помогают выявить и создать более качественные абстракции для нашего кода.
Листинг. Класс с единой ответственностью
public class Version {
public int getMajorVersionNumberO
public int getMinorVersionNumberO
public int getBuildNumberO
}
Вопрос 17
Понятие связности класса. Влияние связности на размер классов
Классы должны иметь небольшое количество переменных экземпляров. Каждый метод класса должен оперировать с одной или несколькими из этих переменных. В общем случае, чем с большим количеством переменных работает метод, тем выше связность этого метода со своим классом. Класс, в котором каждая переменная используется каждым методом, обладает максимальной связностью.
Как правило, создавать классы с максимальной связностью не рекомендуется. С другой стороны, связность класса должна быть высокой. Высокая связность означает, что методы и переменные класса взаимозависимы и существуют как единое целое.
|
|
|
Стратегия компактных функций и коротких списков параметров иногда приводит к росту переменных экземпляров, используемых подмножеством методов.
Поддержание связности приводит к уменьшению классов. Разбиения больших функций на меньшие приводит к росту количества классов. Допустим, имеется большая функция, в которой объявлено много переменных. Вы хотите выделить один небольшой фрагмент этой функции в отдельную функцию. Однако выделяемый код использует четыре переменные, объявленные в исходной функции. Преобразовав эти четыре переменные в переменные экземпляров класса, мы сможем выделить код без передачи переменных. Таким образом, разбиение функции на меньшие фрагменты упрощается.
К сожалению, это также означает, что наши классы теряют связность, потому что в них накапливается все больше переменных экземпляров, созданных исключительно для того, чтобы они могли совместно использоваться небольшим подмножеством функций. Следует разбивать классы, которые утачивают связность.
Таким образом, разбиение большой функции на много мелких функций также часто открывает возможность для выделения нескольких меньших классов.
В результате строение программы улучшается, а ее структура становится более прозрачной.
|
|
|
