- Главная
- Разное
- Бизнес и предпринимательство
- Образование
- Развлечения
- Государство
- Спорт
- Графика
- Культурология
- Еда и кулинария
- Лингвистика
- Религиоведение
- Черчение
- Физкультура
- ИЗО
- Психология
- Социология
- Английский язык
- Астрономия
- Алгебра
- Биология
- География
- Геометрия
- Детские презентации
- Информатика
- История
- Литература
- Маркетинг
- Математика
- Медицина
- Менеджмент
- Музыка
- МХК
- Немецкий язык
- ОБЖ
- Обществознание
- Окружающий мир
- Педагогика
- Русский язык
- Технология
- Физика
- Философия
- Химия
- Шаблоны, картинки для презентаций
- Экология
- Экономика
- Юриспруденция
Что такое findslide.org?
FindSlide.org - это сайт презентаций, докладов, шаблонов в формате PowerPoint.
Обратная связь
Email: Нажмите что бы посмотреть
Презентация на тему Базовые правила и принципы проектирования
Содержание
- 2. О вашем инструктореИмя: Евгений КривошеевСтатусы: SCJP, SCWCD, SCBCD, BEA WLS CA, IBM WAS CAКонтакты: EKrivosheev@luxoft.com
- 3. Цели семинараСеминар призван систематизировать базовые правила и
- 4. Цели семинараДанный семинар – вводный, ~
- 5. Необходимая подготовкаИметь опыт разработки на одном из ООП-языков программированияПонимать ключевые концепции ООПСлушатели должны:
- 6. Организация обученияВремя начала и конца занятийПерерывы
- 7. Конференции УЦ LuxoftКонференции (www.soft-labs.ru): 26 сентября, Киев:
- 8. Ближайшие занятия в ШколахРасписание:Класс руководителя группы разработки.
- 9. План семинара
- 10. ВведениеНаследованиеПолиморфизмКлючевые понятия ООП-проектирования (общеизвестные)
- 11. ВведениеResponsibility (ответственность)Intention (намерение)Coupling (связность)Cohesion (сцепленность, сфокусированность)Granularity (гранулярность, детальность)Ключевые понятия ООП-проектирования (менее известные)
- 12. ВведениеОтветственность – решаемая классом задача из предметной областиФункциональная задачаИнкапсуляция данныхЧаще этот термин применяется для классовResponsibility
- 13. ВведениеНамерение – решаемая разработчиком задачаЧаще этот термин применяется для методовIntention
- 14. ВведениеСвязность – метрика, характеризующая степень зависимости классов
- 15. ВведениеСцепленность (Сфокусированность) – метрика, характеризующая узость ответственности
- 16. ВведениеГранулированность (Детальность) – метрика, характеризующая способ реализации
- 17. ВведениеНаследованиеДелегированиеИнструменты code reuse в ООП
- 18. ВведениеBrian Foote and William F. Opdyke.
- 19. План семинара
- 20. Design RulesЛитературные источники
- 21. Design RulesDesign Ruleshttp://www.laputan.org/drc/drc.html
- 22. Design RulesВ дальнейшем обсуждении мы рассмотрим не
- 23. Design RulesИспользуйте непротиворечивые имена методов [и свойств]Непротиворечивость
- 24. Design RulesИзбегайте смешивания бизнес-логики и логики выбора/ветвленияВ книге [MF] есть аналогичный smell/refactoringDR2. Eliminate Case Analysis
- 25. Design RulesУменьшайте число аргументов/параметровВ книге [MF] есть аналогичный smell/refactoringDR3. Reduce The Number Of Arguments
- 26. Design RulesУменьшайте объем методовВ книге [MF] есть аналогичный smell/refactoringDR4. Reduce The Size Of Methods
- 27. Иерархию наследования стоит проектировать глубокой и узкойDesign RulesDR5. Class Hierarchies Should Be Deep And Narrowдалее
- 28. Design RulesDR5. Class Hierarchies Should Be Deep And Narrowvs
- 29. Design RulesНа вершине иерархии наследования стоит размещать
- 30. Design RulesСтоит минимизировать прямой доступ к переменным
- 31. Design RulesНаследники должны быть специализациями базовых классовСпециализация
- 32. Design RulesРазбивайте большие классыВ книге [MF] есть аналогичный smell/refactoringDR9. Split Large Classes
- 33. Design RulesВ случае серьезной разницы в реализации
- 34. Design RulesРазделяйте несвязанные методыСвязь:по управлениюпо даннымВ книге
- 35. Design RulesДелегируйтеInheritance-based framework vs component-based framework –
- 36. Design RulesПередавайте параметры явноВарианты неявной передачи:глобальные переменныесостояниевнешние
- 37. План семинара
- 38. ВопросыБуду рад ответить на Ваши вопросы
- 39. План семинара
- 40. Design PrinciplesЛитературные источники
- 41. Design PrinciplesDesign PrinciplesDRY : Don’t Repeat Yourself
- 42. Design PrinciplesМинимизируйте повторение кода для снижения затрат
- 43. Design PrinciplesКод должен явно и однозначно отражать намерениеВ книге [MF] есть аналогичный smell/refactoringSCP: Speaking Code
- 44. Design PrinciplesПрограммные сущности (классы, модули, функции) должны
- 45. Design PrinciplesПринцип OCP используется в двух контекстах
- 46. Design PrinciplesOCP: Open/Closed
- 47. Design PrinciplesСуществует два базовых определения:Barbara Liskov «В
- 48. Design PrinciplesLSP: Liskov Substitution
- 49. Design PrinciplesВысокоуровневые модули не должны зависеть от
- 50. Design PrinciplesС помощью абстракций детали системы изолируются
- 51. Design PrinciplesDIP: Dependency Inversionдалееvs
- 52. Design PrinciplesDIP: Dependency Inversionдалее
- 53. Design PrinciplesInversion Of ControlПринцип инверсии управления потоком
- 54. Design PrinciplesНе стоит заставлять клиентов зависеть от
- 55. Design PrinciplesISP: Interface Segregation
- 56. Design PrinciplesThe granule of reuse is the
- 57. Design PrinciplesКлассы в пакете используются совместно. Если
- 58. Design PrinciplesКлассы в пакете должны быть связаны
- 59. Design PrinciplesНе должно быть взаимной зависимости между пакетами, только односторонняя.ADP: Acyclic Dependenciesvs
- 60. Design PrinciplesЗависимости между пакетами должны быть в
- 61. Design PrinciplesСамые стабильные пакеты должны быть самыми
- 62. Design PrinciplesREP : Reuse/Release EquivalenceCRP : Common
- 63. Design PrinciplesTDA – стиль ООП, при котором
- 64. Design PrinciplesОбъекты берут на себя сфокусированные ответственности
- 65. Design PrinciplesРазделяйте ответственности по сфокусированным классамaka Single
- 66. Design PrinciplesSOC : Separation Of Concerns
- 67. План семинараВыводы
- 68. ВопросыБуду рад ответить на Ваши вопросыСсылка на оценочную форму семинара:http://www.luxoft-training.ru/events/vote
- 69. Учебный Центр LuxoftУЦ Luxoft предлагает более 200
- 70. Конференции УЦ LuxoftКонференции (www.soft-labs.ru): 26 сентября, Киев:
- 71. Ближайшие занятия в ШколахРасписание:Класс руководителя группы разработки.
- 72. Скачать презентацию
- 73. Похожие презентации
О вашем инструктореИмя: Евгений КривошеевСтатусы: SCJP, SCWCD, SCBCD, BEA WLS CA, IBM WAS CAКонтакты: EKrivosheev@luxoft.com
![Design RulesИспользуйте непротиворечивые имена методов [и свойств]Непротиворечивость здесь – это одинаковые имена](/img/tmb/12/1102231/cd96a4268594e39b713328002a5cba78-720x.jpg "Базовые правила и принципы проектирования")
![Design RulesИзбегайте смешивания бизнес-логики и логики выбора/ветвленияВ книге [MF] есть аналогичный smell/refactoringDR2. Eliminate Case Analysis](/img/tmb/12/1102231/583fda98ba0915a46cf0b8e892481207-720x.jpg "Базовые правила и принципы проектирования")
![Design RulesУменьшайте число аргументов/параметровВ книге [MF] есть аналогичный smell/refactoringDR3. Reduce The Number Of Arguments](/img/tmb/12/1102231/be34aafae23d77570c4fb33632e7c013-720x.jpg "Базовые правила и принципы проектирования")
![Design RulesУменьшайте объем методовВ книге [MF] есть аналогичный smell/refactoringDR4. Reduce The Size Of Methods](/img/tmb/12/1102231/33f1cb48b00e1bb2427528d03f5f1ae9-720x.jpg "Базовые правила и принципы проектирования")
![Design RulesРазбивайте большие классыВ книге [MF] есть аналогичный smell/refactoringDR9. Split Large Classes](/img/tmb/12/1102231/1a57951b59e3a6a310ad0298083f6ce4-720x.jpg "Базовые правила и принципы проектирования")
![Design RulesРазделяйте несвязанные методыСвязь:по управлениюпо даннымВ книге [MF] есть аналогичный smell/refactoringDR11. Separate](/img/tmb/12/1102231/b4a7f5276f8e9b741e9f661f7f6f3538-720x.jpg "Базовые правила и принципы проектирования")
![Design PrinciplesКод должен явно и однозначно отражать намерениеВ книге [MF] есть аналогичный smell/refactoringSCP: Speaking Code](/img/tmb/12/1102231/9e78504290914e0a9421101cd4257578-720x.jpg "Базовые правила и принципы проектирования")
Слайд 2
О вашем инструкторе
Имя:
Евгений Кривошеев
Статусы:
SCJP, SCWCD, SCBCD, BEA WLS
CA, IBM WAS CA
Слайд 3
Цели семинара
Семинар призван систематизировать базовые правила и принципы
проектирования ПО
Представленные базовые принципы необходимы для понимания более сфокусированных
техник и приемов - рефакторинга и шаблонов проектирования
Слайд 4
Цели семинара
Данный семинар – вводный,
~ 3 мин
на принцип или правило
В дальнейшем будет разработан полноценный курс
Слайд 5
Необходимая подготовка
Иметь опыт разработки на одном из ООП-языков
программирования
Понимать ключевые концепции ООП
Слушатели должны:
Слайд 7
Конференции УЦ Luxoft
Конференции (www.soft-labs.ru):
26 сентября, Киев: TEST
Labs 2009, программа сформирована, регистрация участников
17 ноября, Москва: Req
Labs 2009, открыта регистрация докладчиков15 декабря, Москва: Arch Labs 2009, открыта регистрация докладчиков
Слайд 8
Ближайшие занятия в Школах
Расписание:
Класс руководителя группы разработки. Основные
курсы (24.08.2009-15.09.2009)
Класс менеджера проектов. Основы управления проектами (24.08.2009-17.09.2009)
Класс тест-дизайнера.
Дополнительные курсы (27.08.2009-11.09.2009)Класс java-разработчика. Разработка на базе платформы JavaSE. Экспертный уровень. (31.08.2009-30.09.2009)
http://www.luxoft-training.ru/timetable
Слайд 11
Введение
Responsibility (ответственность)
Intention (намерение)
Coupling (связность)
Cohesion
(сцепленность, сфокусированность)
Granularity
(гранулярность, детальность)
Ключевые
понятия
ООП-проектирования (менее известные)
Слайд 12
Введение
Ответственность – решаемая классом задача из предметной области
Функциональная
задача
Инкапсуляция данных
Чаще этот термин применяется для классов
Responsibility
Слайд 13
Введение
Намерение – решаемая разработчиком задача
Чаще этот термин применяется
для методов
Intention
Слайд 14
Введение
Связность – метрика, характеризующая степень зависимости классов друг
от друга
Loosely coupled vs. Tightly coupled
Классы могут быть связаны
(coupled) различными образами:Зависимые
По управлению
По данным
Coupling
Слайд 15
Введение
Сцепленность (Сфокусированность) – метрика, характеризующая узость ответственности класса
Low
cohesion vs. High cohesion
Классы могут иметь различную сфокусированность (cohesion):
По
функциональностиПо данным
Cohesion
Слайд 16
Введение
Гранулированность (Детальность) – метрика, характеризующая способ реализации намерений
Fine-grained
vs. Coarse-grained
Чаще этот термин применяется для интерфейсов, где намерение
выражается методомGranularity
Слайд 18
Введение
Brian Foote and William F. Opdyke.
Lifecycle and
refactoring patterns that support evolution and reuse, 1995 (отдельно и
в рамках книги Pattern Languages of Program Design vol. 1)Stefan Roock. Refactoring in Large Software, 2006
Martin Fowler. Refactoring: Improving the Design of Existing Code, 1999
Литературные источники семинара
Слайд 22
Design Rules
В дальнейшем обсуждении мы рассмотрим не дословный
перевод правил проектирования, а расширенные современные трактовки
Важно помнить, что
эти правила хоть и распространенные, но контекстные, т.е. их применимость следует обосновыватьDesign Rules
Слайд 23
Design Rules
Используйте непротиворечивые имена методов [и свойств]
Непротиворечивость здесь
– это одинаковые имена для одинаковых намерений
В книге [MF]
есть аналогичный smell/refactoringDR1. Use Consistent Names
DR1. Recursion introduction
Слайд 24
Design Rules
Избегайте смешивания
бизнес-логики и логики выбора/ветвления
В книге
[MF] есть аналогичный smell/refactoring
DR2. Eliminate Case Analysis
Слайд 25
Design Rules
Уменьшайте число аргументов/параметров
В книге [MF] есть аналогичный
smell/refactoring
DR3. Reduce The Number Of Arguments
Слайд 26
Design Rules
Уменьшайте объем методов
В книге [MF] есть аналогичный
smell/refactoring
DR4. Reduce The Size Of Methods
Слайд 27
Иерархию наследования стоит проектировать глубокой и узкой
Design Rules
DR5.
Class Hierarchies Should Be Deep And Narrow
далее
Слайд 29
Design Rules
На вершине иерархии наследования стоит размещать абстракцию
DR6.
The Top Of The Class Hierarchy Should Be Abstract
vs
Слайд 30
Design Rules
Стоит минимизировать прямой доступ к переменным классов
и экземпляров
Encapsulation aka Hiding
В книге [MF] есть аналогичный smell/refactoring
DR7.
Minimize Access to Variables
Слайд 31
Design Rules
Наследники должны быть специализациями базовых классов
Специализация –
отношение
«IS-A», «является»
В книге [MF] есть аналогичный smell/refactoring (Refused
Bequest)DR8. Subclasses Should Be Specializations
Слайд 32
Design Rules
Разбивайте большие классы
В книге [MF] есть аналогичный
smell/refactoring
DR9. Split Large Classes
Слайд 33
Design Rules
В случае серьезной разницы в реализации метода
двумя «братьями» стоит задуматься о целесообразности описания этого метода
в их «отце»Потенциально можно вынести этот метод в иной класс (делегировать)
DR10. Factor Implementation Differences Into Subcomponents
Слайд 34
Design Rules
Разделяйте несвязанные методы
Связь:
по управлению
по данным
В книге [MF]
есть аналогичный smell/refactoring
DR11. Separate Methods That Do Not Communicate
Слайд 35
Design Rules
Делегируйте
Inheritance-based framework vs component-based framework – где
ниже связность?
DR12. Send Messages To Components Instead Of To
Self
Слайд 36
Design Rules
Передавайте параметры явно
Варианты неявной передачи:
глобальные переменные
состояние
внешние источники
данных
Вызов метода, результат которого зависит только от входных параметров
- идемпотентныйDR13. Reduce Implicit Parameter Passing
Слайд 41
Design Principles
Design Principles
DRY : Don’t Repeat Yourself
SCP
: Speaking Code
OCP : Open/Closed
LSP : Liskov Substitution
DIP :
Dependency InversionISP : Interface Segregation
REP : Reuse/Release Equivalence
CRP : Common Reuse
CCP : Common Closure
ADP : Acyclic Dependencies
SDP : Stable Dependencies
SAP : Stable Abstractions
TDA : Tell, Don’t Ask
SOC : Separation Of Concerns
Stefan Roock. Refactoring in Large Software. 2006
Слайд 42
Design Principles
Минимизируйте повторение кода для снижения затрат на
поддержку
aka Single Point of Truth or Single Point of
MaintenanceВ книге [MF] есть аналогичный smell/refactoring
DRY: Don’t Repeat Yourself
Слайд 43
Design Principles
Код должен явно и однозначно отражать намерение
В
книге [MF] есть аналогичный smell/refactoring
SCP: Speaking Code
Слайд 44
Design Principles
Программные сущности (классы, модули, функции) должны быть
открыты для расширения и закрыты для изменения
«Открыты для расширения»
- возможно расширять и изменять поведение приложения при изменении требований«Закрыты для изменения» - расширение поведения не приводит к изменению исходного или бинарного кода
OCP: Open/Closed
далее
Слайд 45
Design Principles
Принцип OCP используется в двух контекстах его
реализации:
Dr. Bertrand Meyer's Open/Closed Principle
«Написанная реализация класса модифицируется только
для исправления ошибок, новые ответственности или изменение существующих потребует создание нового класса, возможно, наследника. Этот новый класс не обязан реализовать тот же интерфейс.»Polymorphic Open/Closed Principle Более современная версия. «Множество реализаций классов можно использовать полиморфно, через один и тот же интерфейс.» Здесь зафиксирована интерфейсная часть, а реализация вариативна.
См. так же «Protected Variation»
OCP: Open/Closed
далее
Слайд 47
Design Principles
Существует два базовых определения:
Barbara Liskov
«В коде приложения
класс всегда можно заменить его наследником»
Bertrand Meyer ("Design-by-Contract" formulation)
«Наследники
должны соблюдать контракт предка»LSP: Liskov Substitution
далее
Слайд 49
Design Principles
Высокоуровневые модули не должны зависеть от низкоуровневых.
И те, и другие должны зависеть от абстракций.
Абстракции не
должны зависеть от деталей. Детали должны зависеть от абстракции. DIP: Dependency Inversion
далее
Слайд 50
Design Principles
С помощью абстракций детали системы изолируются друг
от друга
Легко менять детали реализации без модификации высокоуровневой логики
Шаблоны,
с помощью которых реализуется принцип DIP:Plug-in, [A] Factory [M], Service Locator, Inversion of Control, Dependency Injection
DIP: Dependency Inversion
далее
Слайд 53
Design Principles
Inversion Of Control
Принцип инверсии управления потоком выполнения
по сравнению с процедурным программированием
Основа всех каркасов (frameworks)
aka Hollywood
PrincipleDependency Injection
Шаблон проектирования
Не мы сами получаем необходимые объекты, а внешняя среда нам их передает
DIP → IoC → Dependency Injection
Слайд 54
Design Principles
Не стоит заставлять клиентов зависеть от ненужных
им интерфейсов
Вместо одного многофункционального интерфейса лучше выделить несколько узкоспециальных
ISP:
Interface Segregationдалее
Слайд 56
Design Principles
The granule of reuse is the granule
of release. Only components that are released through a
tracking system can be effectively reused. This granule is the packageМногократно используемая единица кода должна пройти завершенный цикл разработки – система контроля версий, багтрекер, тесты. Эта единица – пакет.
REP и ряд следующих принципов – макропринципы организации разработки и пакетирования кода
REP: Reuse/Release Equivalence
Слайд 57
Design Principles
Классы в пакете используются совместно. Если используется
один класс из пакета, считается что используются все.
Здесь использование
– многократное использование при дальнейшей разработкеCRP: Common Reuse
Слайд 58
Design Principles
Классы в пакете должны быть связаны одинаковой
причиной их изменения. Изменение пакета (одного из классов) касается
всех классов в нем.CCP: Common Closure
Слайд 59
Design Principles
Не должно быть взаимной зависимости между пакетами,
только односторонняя.
ADP: Acyclic Dependencies
vs
Слайд 60
Design Principles
Зависимости между пакетами должны быть в сторону
более стабильного. Пакет должен зависеть только от более стабильного
пакета, чем он сам.Стабильность модуля, класса или пакета – степень сложности его изменений
Стабильные классы – независимые классы (незачем менять) или сильнозависимые (множество причин не менять)
SDP: Stable Dependencies
Слайд 61
Design Principles
Самые стабильные пакеты должны быть самыми абстрактными.
Нестабильные пакеты должны быть конкретными. Степень абстракции пакета должна
зависеть от его стабильности.SAP: Stable Abstractions
Слайд 62
Design Principles
REP : Reuse/Release
Equivalence
CRP : Common Reuse
CCP
: Common Closure
ADP : Acyclic Dependencies
SDP : Stable Dependencies
SAP
: Stable Abstractions
Слайд 63
Design Principles
TDA – стиль ООП, при котором объектА
сигнализирует объектуБ выполнить его ответственность, вместо того, чтобы что-либо
спрашивать у него и выполнять ответственность самомуTDA: Tell, Don’t Ask
далее
Слайд 64
Design Principles
Объекты берут на себя сфокусированные ответственности и
делегируют остальные ответственности другим объектам
ООП vs Процедурный стиль
См. так
же «Low Of Demeter»TDA: Tell, Don’t Ask
Слайд 65
Design Principles
Разделяйте ответственности по сфокусированным классам
aka Single Responsibility
Principle
«Класс должен иметь только одну причину изменения»
SOC: Separation Of
Concernsдалее
Слайд 68
Вопросы
Буду рад ответить на Ваши вопросы
Ссылка на оценочную
форму семинара:
http://www.luxoft-training.ru/events/vote
Слайд 69
Учебный Центр Luxoft
УЦ Luxoft предлагает более 200 курсов
и тренингов по различным направлениям промышленной разработки ПО
Наши инструкторы
– практики, готовые передать свою экспертизуhttp://luxoft-training.ru
Слайд 70
Конференции УЦ Luxoft
Конференции (www.soft-labs.ru):
26 сентября, Киев: TEST
Labs 2009, программа сформирована, регистрация участников
17 ноября, Москва: Req
Labs 2009, открыта регистрация докладчиков15 декабря, Москва: Arch Labs 2009, открыта регистрация докладчиков
Слайд 71
Ближайшие занятия в Школах
Расписание:
Класс руководителя группы разработки. Основные
курсы (24.08.2009-15.09.2009)
Класс менеджера проектов. Основы управления проектами (24.08.2009-17.09.2009)
Класс тест-дизайнера.
Дополнительные курсы (27.08.2009-11.09.2009)Класс java-разработчика. Разработка на базе платформы JavaSE. Экспертный уровень. (31.08.2009-30.09.2009)
http://www.luxoft-training.ru/timetable
