
- •Вопрос 2 3
- •Вопрос 2 Структурное программирование. Проектирование сверху вниз. Модульное программирование. Структурное кодирование
- •Вопрос 4 Функции. Компактность. Правило одной операции. Опасность смешения уровней абстракции
- •Вопрос 5 Функции. Правило понижения. Паттерн «Абстрактная фабрика» и использование оператора switch
- •Вопрос 6 Аргументы функций. Приемлемое количество и качество аргументов. Побочные эффекты в функциях. Примеры
- •Вопрос 9 Форматирование исходного кода. Цель форматирования. Вертикальное разделение концепций, вертикальное сжатие. Вертикальное расстояние
- •Вопрос 10 Форматирование исходного кода. Цель форматирования. Горизонтальное форматирование. Горизонтальное разделение и сжатие. Отступы
- •Вопрос 11 Объекты и структуры данных. Отличия процедурного и объектно-ориентированного кода. Случаи применения
- •Вопрос 12 Закон Деметры. Опасность построения гибридов объектов и структур данных. Объекты передачи данных и активные записи
- •Вопрос 16 Класс. Размеры класса. Принцип единой ответственности (srp)
- •Вопрос 17 Понятие связности класса. Влияние связности на размер классов
- •Вопрос 18 Структурирование класса с учетом его изменений. Принципы проектирования классов в ооп
- •Вопрос 19 Понятие эффективности программы. Выбор между эффективностью и удобочитаемостью. Оптимизирующие компиляторы
- •Вопрос 24 Понятие отладки. Отличие между отладкой и тестированием. Средства отладки. Защитное программирование
- •Вопрос 28 Понятие правильности программ. Доказательство правильности программ
Вопрос 16 Класс. Размеры класса. Принцип единой ответственности (srp)
По стандартным правилам класс должен начинаться со списка переменных. Сначала перечисляются открытые статические константы. Далее следуют приватные статические переменные, а за ними идут приватные переменные экземпляров. За списком переменных обычно следуют открытые функции. Такое размещение соответствует правилу понижения, в результате чего программа читается как газетная статья.
Первое правило: классы должны быть компактными. Второе правило: классы должны быть еще компактнее.
В классах используется другая метрика; мы подсчитываем ответственности [RDD].
Имя класса должно описывать его ответственности. В сущности, имя должно стать первым фактором, способствующим определению размера класса. Если для класса не удается подобрать четкое, короткое имя, вероятно, он слишком велик. Чем туманнее имя класса, тем больше вероятность, что он имеет слишком много ответственностей.
Краткое описание класса должно укладываться примерно в 25 слов, без выражений «если», «и», «или» и «но
Принцип единой ответственности (SRP)
Принцип единой ответственности (SRP1) утверждает, что класс или модуль должен иметь одну — и только одну — причину для изменения.
Этот принцип дает нам как определение ответственности, так и критерий для оценки размера класса. Классы должны иметь одну ответственность, то есть одну причину для изменений.
Попытки идентификации ответственностей (причин для изменения) часто помогают выявить и создать более качественные абстракции для нашего кода.
Листинг. Класс с единой ответственностью
public class Version {
public int getMajorVersionNumberO
public int getMinorVersionNumberO
public int getBuildNumberO
}
Вопрос 17 Понятие связности класса. Влияние связности на размер классов
Классы должны иметь небольшое количество переменных экземпляров. Каждый метод класса должен оперировать с одной или несколькими из этих переменных. В общем случае, чем с большим количеством переменных работает метод, тем выше связность этого метода со своим классом. Класс, в котором каждая переменная используется каждым методом, обладает максимальной связностью.
Как правило, создавать классы с максимальной связностью не рекомендуется. С другой стороны, связность класса должна быть высокой. Высокая связность означает, что методы и переменные класса взаимозависимы и существуют как единое целое.
Стратегия компактных функций и коротких списков параметров иногда приводит к росту переменных экземпляров, используемых подмножеством методов.
Поддержание связности приводит к уменьшению классов. Разбиения больших функций на меньшие приводит к росту количества классов. Допустим, имеется большая функция, в которой объявлено много переменных. Вы хотите выделить один небольшой фрагмент этой функции в отдельную функцию. Однако выделяемый код использует четыре переменные, объявленные в исходной функции. Преобразовав эти четыре переменные в переменные экземпляров класса, мы сможем выделить код без передачи переменных. Таким образом, разбиение функции на меньшие фрагменты упрощается.
К сожалению, это также означает, что наши классы теряют связность, потому что в них накапливается все больше переменных экземпляров, созданных исключительно для того, чтобы они могли совместно использоваться небольшим подмножеством функций. Следует разбивать классы, которые утачивают связность.
Таким образом, разбиение большой функции на много мелких функций также часто открывает возможность для выделения нескольких меньших классов.
В результате строение программы улучшается, а ее структура становится более прозрачной.