АФТИ ООП 2013-2014. Лекция I/09

Transcript

1. ОБЪЕКТНО- ОРИЕНТИРОВАННОЕ ПРОГРАММИРОВАНИЕ Лекция № 9
 11.11.2013 г.
2. ПРИНЦИП ОТДЕЛЕНИЯ ИНТЕРФЕЙСА • Interface Segregation Principle (ISP). • Клиенты не должны попадать в зависимость от методов, которыми они не пользуются.
3. class Door { public: virtual void lock() = 0; virtual void unlock() = 0; virtual bool isOpen() = 0; }; ! class Timer { public: void register(int timeout, TimerClient *client); }; ! class TimerClient { public: virtual void timeout() = 0; }; Как сделать класс TimedDoor с сигналом о незакрытии?
4. Timer TimerClient Door TimedDoor Вариант решения: наследуем Door от TimerClient
5. ПРОБЛЕМЫ
6. ПРОБЛЕМЫ • Door не имеет никакого отношения к таймеру! (SRP)
7. ПРОБЛЕМЫ • Door не имеет никакого отношения к таймеру! (SRP) • Все пользователи Door должны тащить за собой TimerClient (и зависеть от изменений в оном).
8. ПРОБЛЕМЫ • Door не имеет никакого отношения к таймеру! (SRP) • Все пользователи Door должны тащить за собой TimerClient (и зависеть от изменений в оном). • Возможное нарушение принципа LSP.
9. ПРОБЛЕМЫ • Door не имеет никакого отношения к таймеру! (SRP) • Все пользователи Door должны тащить за собой TimerClient (и зависеть от изменений в оном). • Возможное нарушение принципа LSP. • Если увлекаться подобным подходом, базовый класс будет излишне тучным, а производные — недомерками.
10. Timer TimerClient Door TimedDoor DoorTimer
 Adapter Другой вариант: посредством DoorTimeAdapter
11. Timer TimerClient Door TimedDoor Третий вариант: множественное наследование
12. SOLID Single responsibility principle
 Open-closed principle Liskov substitution principle Interface Segregation Principle Dependency Inversion principle Solid – прочный, крепкий, надежный…
13. ПРАКТИЧЕСКОЕ РУКОВОДСТВО
14. 1. ПЛАНИРОВАНИЕ
15. 1. ПЛАНИРОВАНИЕ • Отделяем то, что будем делать сейчас и в ближайшее время, от планов на будущее.
16. 1. ПЛАНИРОВАНИЕ • Отделяем то, что будем делать сейчас и в ближайшее время, от планов на будущее. • Лучше всего браться за нечто простое, но цельное.
17. 1. ПЛАНИРОВАНИЕ • Отделяем то, что будем делать сейчас и в ближайшее время, от планов на будущее. • Лучше всего браться за нечто простое, но цельное. • 90 % сил — сделать хорошо то, что «есть»
 10 % сил — «зарубки» на будущее.
18. 2. КЛАССЫ И ОБЪЕКТЫ
19. 2. КЛАССЫ И ОБЪЕКТЫ • Выделяем основополагающие объекты.
20. 2. КЛАССЫ И ОБЪЕКТЫ • Выделяем основополагающие объекты. • …если не получается: берем описание проекта и смотрим на самые часто встречающиеся существительные.
21. 2. КЛАССЫ И ОБЪЕКТЫ • Выделяем основополагающие объекты. • …если не получается: берем описание проекта и смотрим на самые часто встречающиеся существительные. • Смотрим на связи (наследование, композиция, связь через другой объект, …)
22. 2. КЛАССЫ И ОБЪЕКТЫ • Выделяем основополагающие объекты. • …если не получается: берем описание проекта и смотрим на самые часто встречающиеся существительные. • Смотрим на связи (наследование, композиция, связь через другой объект, …) • Ищем понятную простую, но цельную подсистему, с которой и начинаем, потом ищем еще одну…
23. 3. ЯДРО И ПРОТОТИП
24. 3. ЯДРО И ПРОТОТИП • Признаки «ядерности»:
25. 3. ЯДРО И ПРОТОТИП • Признаки «ядерности»: • Ключевые алгоритмы.
26. 3. ЯДРО И ПРОТОТИП • Признаки «ядерности»: • Ключевые алгоритмы. • Наиболее широко используемые абстракции.
27. 3. ЯДРО И ПРОТОТИП • Признаки «ядерности»: • Ключевые алгоритмы. • Наиболее широко используемые абстракции. • Нет аддитивности. Убираем модуль — все рушится.
28. 3. ЯДРО И ПРОТОТИП • Признаки «ядерности»: • Ключевые алгоритмы. • Наиболее широко используемые абстракции. • Нет аддитивности. Убираем модуль — все рушится. • Признаки периферийности:
29. 3. ЯДРО И ПРОТОТИП • Признаки «ядерности»: • Ключевые алгоритмы. • Наиболее широко используемые абстракции. • Нет аддитивности. Убираем модуль — все рушится. • Признаки периферийности: • Частные случаи («поддержка 100 форматов файлов»).
30. 3. ЯДРО И ПРОТОТИП • Признаки «ядерности»: • Ключевые алгоритмы. • Наиболее широко используемые абстракции. • Нет аддитивности. Убираем модуль — все рушится. • Признаки периферийности: • Частные случаи («поддержка 100 форматов файлов»). • Есть аддитивность. Убрали модуль — общий функционал чуть-чуть уменьшился.
31. На первом этапе нужно вкладываться в ядро и довольствоваться 
 простой периферией! Ядро (прототип) + 
 простенькая периферия = 
 первая версия системы!
32. ЗАТЫЧКИ • При объявленном полном интерфейсе класса реализация является: • пустой; • неполной (частный случай); • медленной; • приближенной; • …но зато пишется мгновенно!
33. 4. ДАЛЬНЕЙШЕЕ РАЗВИТИЕ
34. 4. ДАЛЬНЕЙШЕЕ РАЗВИТИЕ • Переход от взрывного роста к эволюционному.
35. 4. ДАЛЬНЕЙШЕЕ РАЗВИТИЕ • Переход от взрывного роста к эволюционному. • Любые изменения не должны ухудшать работоспособность системы, качество кода и документации, нарушать конвенции.
36. 4. ДАЛЬНЕЙШЕЕ РАЗВИТИЕ • Переход от взрывного роста к эволюционному. • Любые изменения не должны ухудшать работоспособность системы, качество кода и документации, нарушать конвенции. • Либо мы находим способ интегрировать новое, либо делаем отдельную систему.
37. ВЫЯВЛЕНИЕ «БЯКИ»
38. ВЫЯВЛЕНИЕ «БЯКИ» • Реализация «бяки» плоха.
39. ВЫЯВЛЕНИЕ «БЯКИ» • Реализация «бяки» плоха. переписать!
40. ВЫЯВЛЕНИЕ «БЯКИ» • Реализация «бяки» плоха. • Реализация «бяки» сама по себе хороша, но при включении в систему нарушаются принципы ООП. переписать!
41. ВЫЯВЛЕНИЕ «БЯКИ» • Реализация «бяки» плоха. • Реализация «бяки» сама по себе хороша, но при включении в систему нарушаются принципы ООП. переписать! рефакторинг!
42. ВЫЯВЛЕНИЕ «БЯКИ» • Реализация «бяки» плоха. • Реализация «бяки» сама по себе хороша, но при включении в систему нарушаются принципы ООП. • «Бяка» ставит под сомнение какой-то фундаментальный принцип или ограничение, заложенное в ядро. переписать! рефакторинг!
43. ВЫЯВЛЕНИЕ «БЯКИ» • Реализация «бяки» плоха. • Реализация «бяки» сама по себе хороша, но при включении в систему нарушаются принципы ООП. • «Бяка» ставит под сомнение какой-то фундаментальный принцип или ограничение, заложенное в ядро. переписать! рефакторинг! проектирование заново
 с учетом переделок
44. САМОДОКУМЕНТИРУЕМОСТЬ
45. САМОДОКУМЕНТИРУЕМОСТЬ • Работа сознания человека: 
 имя → ассоциативные поля → понимание → действие.
46. САМОДОКУМЕНТИРУЕМОСТЬ • Работа сознания человека: 
 имя → ассоциативные поля → понимание → действие. • Имя переменной: смысл ее значения.
47. САМОДОКУМЕНТИРУЕМОСТЬ • Работа сознания человека: 
 имя → ассоциативные поля → понимание → действие. • Имя переменной: смысл ее значения. • Имя функции/метода: суть ее поведения.
48. САМОДОКУМЕНТИРУЕМОСТЬ • Работа сознания человека: 
 имя → ассоциативные поля → понимание → действие. • Имя переменной: смысл ее значения. • Имя функции/метода: суть ее поведения. • Имя класса: смысл в общем контексте.
49. САМОДОКУМЕНТИРУЕМОСТЬ • Работа сознания человека: 
 имя → ассоциативные поля → понимание → действие. • Имя переменной: смысл ее значения. • Имя функции/метода: суть ее поведения. • Имя класса: смысл в общем контексте. • Если смысл меняется, должно меняться и имя!
50. МОДИФИЦИРУЕМОСТЬ
51. МОДИФИЦИРУЕМОСТЬ • 100 % кода должно быть модифицируемым.
52. МОДИФИЦИРУЕМОСТЬ • 100 % кода должно быть модифицируемым. • Какой-то код придется выбрасывать в любом случае, нужно относиться к этому спокойно.
53. МОДИФИЦИРУЕМОСТЬ • 100 % кода должно быть модифицируемым. • Какой-то код придется выбрасывать в любом случае, нужно относиться к этому спокойно. • «Код на выброс» — не боимся экспериментировать.
55. Планирование Выявление классов Прототип «Долизывание»
56. КОНЕЦ ДЕВЯТОЙ ЛЕКЦИИ