Содержание
- 2. О вашем инструкторе Имя: Евгений Кривошеев Статусы: SCJP, SCWCD, SCBCD, BEA WLS CA, IBM WAS CA
- 3. Цели семинара Семинар призван систематизировать базовые правила и принципы проектирования ПО Представленные базовые принципы необходимы для
- 4. Цели семинара Данный семинар – вводный, ~ 3 мин на принцип или правило В дальнейшем будет
- 5. Необходимая подготовка Иметь опыт разработки на одном из ООП-языков программирования Понимать ключевые концепции ООП Слушатели должны:
- 6. Организация обучения Время начала и конца занятий Перерывы
- 7. Конференции УЦ Luxoft Конференции (www.soft-labs.ru): 26 сентября, Киев: TEST Labs 2009, программа сформирована, регистрация участников 17
- 8. Ближайшие занятия в Школах Расписание: Класс руководителя группы разработки. Основные курсы (24.08.2009-15.09.2009) Класс менеджера проектов. Основы
- 9. План семинара
- 10. Введение Наследование Полиморфизм Ключевые понятия ООП-проектирования (общеизвестные)
- 11. Введение Responsibility (ответственность) Intention (намерение) Coupling (связность) Cohesion (сцепленность, сфокусированность) Granularity (гранулярность, детальность) Ключевые понятия ООП-проектирования
- 12. Введение Ответственность – решаемая классом задача из предметной области Функциональная задача Инкапсуляция данных Чаще этот термин
- 13. Введение Намерение – решаемая разработчиком задача Чаще этот термин применяется для методов Intention
- 14. Введение Связность – метрика, характеризующая степень зависимости классов друг от друга Loosely coupled vs. Tightly coupled
- 15. Введение Сцепленность (Сфокусированность) – метрика, характеризующая узость ответственности класса Low cohesion vs. High cohesion Классы могут
- 16. Введение Гранулированность (Детальность) – метрика, характеризующая способ реализации намерений Fine-grained vs. Coarse-grained Чаще этот термин применяется
- 17. Введение Наследование Делегирование Инструменты code reuse в ООП
- 18. Введение Brian Foote and William F. Opdyke. Lifecycle and refactoring patterns that support evolution and reuse,
- 19. План семинара
- 20. Design Rules Литературные источники
- 21. Design Rules Design Rules http://www.laputan.org/drc/drc.html
- 22. Design Rules В дальнейшем обсуждении мы рассмотрим не дословный перевод правил проектирования, а расширенные современные трактовки
- 23. Design Rules Используйте непротиворечивые имена методов [и свойств] Непротиворечивость здесь – это одинаковые имена для одинаковых
- 24. Design Rules Избегайте смешивания бизнес-логики и логики выбора/ветвления В книге [MF] есть аналогичный smell/refactoring DR2. Eliminate
- 25. Design Rules Уменьшайте число аргументов/параметров В книге [MF] есть аналогичный smell/refactoring DR3. Reduce The Number Of
- 26. Design Rules Уменьшайте объем методов В книге [MF] есть аналогичный smell/refactoring DR4. Reduce The Size Of
- 27. Иерархию наследования стоит проектировать глубокой и узкой Design Rules DR5. Class Hierarchies Should Be Deep And
- 28. Design Rules DR5. Class Hierarchies Should Be Deep And Narrow vs
- 29. Design Rules На вершине иерархии наследования стоит размещать абстракцию DR6. The Top Of The Class Hierarchy
- 30. Design Rules Стоит минимизировать прямой доступ к переменным классов и экземпляров Encapsulation aka Hiding В книге
- 31. Design Rules Наследники должны быть специализациями базовых классов Специализация – отношение «IS-A», «является» В книге [MF]
- 32. Design Rules Разбивайте большие классы В книге [MF] есть аналогичный smell/refactoring DR9. Split Large Classes
- 33. Design Rules В случае серьезной разницы в реализации метода двумя «братьями» стоит задуматься о целесообразности описания
- 34. Design Rules Разделяйте несвязанные методы Связь: по управлению по данным В книге [MF] есть аналогичный smell/refactoring
- 35. Design Rules Делегируйте Inheritance-based framework vs component-based framework – где ниже связность? DR12. Send Messages To
- 36. Design Rules Передавайте параметры явно Варианты неявной передачи: глобальные переменные состояние внешние источники данных Вызов метода,
- 37. План семинара
- 38. Вопросы Буду рад ответить на Ваши вопросы
- 39. План семинара
- 40. Design Principles Литературные источники
- 41. Design Principles Design Principles DRY : Don’t Repeat Yourself SCP : Speaking Code OCP : Open/Closed
- 42. Design Principles Минимизируйте повторение кода для снижения затрат на поддержку aka Single Point of Truth or
- 43. Design Principles Код должен явно и однозначно отражать намерение В книге [MF] есть аналогичный smell/refactoring SCP:
- 44. Design Principles Программные сущности (классы, модули, функции) должны быть открыты для расширения и закрыты для изменения
- 45. Design Principles Принцип OCP используется в двух контекстах его реализации: Dr. Bertrand Meyer's Open/Closed Principle «Написанная
- 46. Design Principles OCP: Open/Closed
- 47. Design Principles Существует два базовых определения: Barbara Liskov «В коде приложения класс всегда можно заменить его
- 48. Design Principles LSP: Liskov Substitution
- 49. Design Principles Высокоуровневые модули не должны зависеть от низкоуровневых. И те, и другие должны зависеть от
- 50. Design Principles С помощью абстракций детали системы изолируются друг от друга Легко менять детали реализации без
- 51. Design Principles DIP: Dependency Inversion далее vs
- 52. Design Principles DIP: Dependency Inversion далее
- 53. Design Principles Inversion Of Control Принцип инверсии управления потоком выполнения по сравнению с процедурным программированием Основа
- 54. Design Principles Не стоит заставлять клиентов зависеть от ненужных им интерфейсов Вместо одного многофункционального интерфейса лучше
- 55. Design Principles ISP: Interface Segregation
- 56. Design Principles The granule of reuse is the granule of release. Only components that are released
- 57. Design Principles Классы в пакете используются совместно. Если используется один класс из пакета, считается что используются
- 58. Design Principles Классы в пакете должны быть связаны одинаковой причиной их изменения. Изменение пакета (одного из
- 59. Design Principles Не должно быть взаимной зависимости между пакетами, только односторонняя. ADP: Acyclic Dependencies vs
- 60. Design Principles Зависимости между пакетами должны быть в сторону более стабильного. Пакет должен зависеть только от
- 61. Design Principles Самые стабильные пакеты должны быть самыми абстрактными. Нестабильные пакеты должны быть конкретными. Степень абстракции
- 62. Design Principles REP : Reuse/Release Equivalence CRP : Common Reuse CCP : Common Closure ADP :
- 63. Design Principles TDA – стиль ООП, при котором объектА сигнализирует объектуБ выполнить его ответственность, вместо того,
- 64. Design Principles Объекты берут на себя сфокусированные ответственности и делегируют остальные ответственности другим объектам ООП vs
- 65. Design Principles Разделяйте ответственности по сфокусированным классам aka Single Responsibility Principle «Класс должен иметь только одну
- 66. Design Principles SOC : Separation Of Concerns
- 67. План семинара Выводы
- 68. Вопросы Буду рад ответить на Ваши вопросы Ссылка на оценочную форму семинара: http://www.luxoft-training.ru/events/vote
- 69. Учебный Центр Luxoft УЦ Luxoft предлагает более 200 курсов и тренингов по различным направлениям промышленной разработки
- 70. Конференции УЦ Luxoft Конференции (www.soft-labs.ru): 26 сентября, Киев: TEST Labs 2009, программа сформирована, регистрация участников 17
- 71. Ближайшие занятия в Школах Расписание: Класс руководителя группы разработки. Основные курсы (24.08.2009-15.09.2009) Класс менеджера проектов. Основы
- 73. Скачать презентацию