ориентированного
программирования
Решение: декомпозиция
• Самое простое — декомпозиция на понятные по
смыслу операции (ф-и и методы) и наименование
их соответствующим образом
• Возможны и более сложные декомпозиции, такие,
как мы применили в случае разбиения на команды
Сложные логические структуры (if/else switch/case
for/while)
● Большое количество
● Большая вложенность
● А ТАКЖЕ ОПЕРАТОР goto!
● Решение: все то же самое — декомпозиция
Длинный список параметров
одержимость примитивами
Длинный список параметров
• Скорее всего либо неправильно декомпозирован
метод, либо неправильно выбраны параметры
• Решение
– Разделить метод на несколько с меньшим
количеством параметров
– Объединить параметры в сущность более
высокого уровня
• Одержимость примитивами или связки
данных
– Если примитивные данные появляются все время
«в связке», вероятно, они принадлежат друг
другу?
– Не используйте примитивные типы данных как
«босяцкую» замену классам. Если данные
сложны, напишите класс
Чрезмерное использование
литеральных констант
Commands.
Чрезмерное использование
литеральных констант
• Чрезмерно длинные
• Чрезмерно короткие
• И то и другое затрудняет читаемость кода.
Идентификаторы должны быть с одной стороны,
читаемы, с другой – понятными.
• Имена объектов должны объяснять, для чего нужны
объекты
Идентификаторы
Принципы ООП
Принципы здравого смысла
Don't-Repeat Yourself
(не повторяйся)
ependency inversion
nterface segregation
iskov Substitution
pen / close
ingle Responsibility
Open-Close Principle
(принцип открыто-закрыто)
?
DIP: Векторная графика
Liskov Substitution Principle
(Принцип подстановки Лисков)
• Объект базового типа можно заменить объектом
производного типа без ущерба для
правильности работы программы
• Наследуемый класс не может иметь более
сильных пред-условий или более слабых пост-
условий.
• Наследуемый класс не может
– Требовать большего
– Обещать меньшее
LSP: Прямоугольник и квадрат
LSP: Прямоугольник и квадрат
LSP: System.Collections.IList
Спасибо за внимание.
Вопросы?