Что такое findslide.org?

FindSlide.org - это сайт презентаций, докладов, шаблонов в формате PowerPoint.

Для правообладателей

Обратная связь

Email: Нажмите что бы посмотреть 

Яндекс.Метрика

Презентация на тему Базовые правила и принципы проектирования

Содержание

О вашем инструктореИмя: Евгений КривошеевСтатусы: SCJP, SCWCD, SCBCD, BEA WLS CA, IBM WAS CAКонтакты: EKrivosheev@luxoft.com
Базовые правила и принципы проектирования ПОЕвгений КривошеевEKrivosheev@luxoft.com О вашем инструктореИмя: Евгений КривошеевСтатусы: SCJP, SCWCD, SCBCD, BEA WLS CA, IBM WAS CAКонтакты: EKrivosheev@luxoft.com Цели семинараСеминар призван систематизировать базовые правила и принципы проектирования ПОПредставленные базовые принципы Цели семинараДанный семинар – вводный, ~ 3 мин на принцип или Необходимая подготовкаИметь опыт разработки на одном из ООП-языков программированияПонимать ключевые концепции ООПСлушатели должны: Организация обученияВремя начала и конца занятийПерерывы Конференции УЦ LuxoftКонференции (www.soft-labs.ru): 26 сентября, Киев: TEST Labs 2009, программа сформирована, Ближайшие занятия в ШколахРасписание:Класс руководителя группы разработки. Основные курсы (24.08.2009-15.09.2009)Класс менеджера проектов. План семинара ВведениеНаследованиеПолиморфизмКлючевые понятия ООП-проектирования (общеизвестные) ВведениеResponsibility (ответственность)Intention (намерение)Coupling (связность)Cohesion (сцепленность, сфокусированность)Granularity (гранулярность, детальность)Ключевые понятия ООП-проектирования (менее известные) ВведениеОтветственность – решаемая классом задача из предметной областиФункциональная задачаИнкапсуляция данныхЧаще этот термин применяется для классовResponsibility ВведениеНамерение – решаемая разработчиком задачаЧаще этот термин применяется для методовIntention ВведениеСвязность – метрика, характеризующая степень зависимости классов друг от другаLoosely coupled vs. ВведениеСцепленность (Сфокусированность) – метрика, характеризующая узость ответственности классаLow cohesion vs. High cohesionКлассы ВведениеГранулированность (Детальность) – метрика, характеризующая способ реализации намеренийFine-grained vs. Coarse-grainedЧаще этот термин ВведениеНаследованиеДелегированиеИнструменты code reuse в ООП ВведениеBrian Foote and William F. Opdyke. Lifecycle and refactoring patterns План семинара Design RulesЛитературные источники Design RulesDesign Ruleshttp://www.laputan.org/drc/drc.html Design RulesВ дальнейшем обсуждении мы рассмотрим не дословный перевод правил проектирования, а Design RulesИспользуйте непротиворечивые имена методов [и свойств]Непротиворечивость здесь – это одинаковые имена Design RulesИзбегайте смешивания бизнес-логики и логики выбора/ветвленияВ книге [MF] есть аналогичный smell/refactoringDR2. Eliminate Case Analysis Design RulesУменьшайте число аргументов/параметровВ книге [MF] есть аналогичный smell/refactoringDR3. Reduce The Number Of Arguments Design RulesУменьшайте объем методовВ книге [MF] есть аналогичный smell/refactoringDR4. Reduce The Size Of Methods Иерархию наследования стоит проектировать глубокой и узкойDesign RulesDR5. Class Hierarchies Should Be Deep And Narrowдалее Design RulesDR5. Class Hierarchies Should Be Deep And Narrowvs Design RulesНа вершине иерархии наследования стоит размещать абстракциюDR6. The Top Of The Design RulesСтоит минимизировать прямой доступ к переменным классов и экземпляровEncapsulation aka HidingВ Design RulesНаследники должны быть специализациями базовых классовСпециализация – отношение «IS-A», «является»В Design RulesРазбивайте большие классыВ книге [MF] есть аналогичный smell/refactoringDR9. Split Large Classes Design RulesВ случае серьезной разницы в реализации метода двумя «братьями» стоит задуматься Design RulesРазделяйте несвязанные методыСвязь:по управлениюпо даннымВ книге [MF] есть аналогичный smell/refactoringDR11. Separate Design RulesДелегируйтеInheritance-based framework vs component-based framework – где ниже связность?DR12. Send Messages Design RulesПередавайте параметры явноВарианты неявной передачи:глобальные переменныесостояниевнешние источники данныхВызов метода, результат которого План семинара ВопросыБуду рад ответить на Ваши вопросы План семинара Design PrinciplesЛитературные источники Design PrinciplesDesign PrinciplesDRY : Don’t Repeat Yourself SCP : Speaking CodeOCP : Design PrinciplesМинимизируйте повторение кода для снижения затрат на поддержкуaka Single Point of Design PrinciplesКод должен явно и однозначно отражать намерениеВ книге [MF] есть аналогичный smell/refactoringSCP: Speaking Code Design PrinciplesПрограммные сущности (классы, модули, функции) должны быть открыты для расширения и Design PrinciplesПринцип OCP используется в двух контекстах его реализации:Dr. Bertrand Meyer's Open/Closed Design PrinciplesOCP: Open/Closed Design PrinciplesСуществует два базовых определения:Barbara Liskov «В коде приложения класс всегда можно Design PrinciplesLSP: Liskov Substitution Design PrinciplesВысокоуровневые модули не должны зависеть от низкоуровневых. И те, и другие Design PrinciplesС помощью абстракций детали системы изолируются друг от другаЛегко менять детали Design PrinciplesDIP: Dependency Inversionдалееvs Design PrinciplesDIP: Dependency Inversionдалее Design PrinciplesInversion Of ControlПринцип инверсии управления потоком выполнения по сравнению с процедурным Design PrinciplesНе стоит заставлять клиентов зависеть от ненужных им интерфейсовВместо одного многофункционального Design PrinciplesISP: Interface Segregation Design PrinciplesThe granule of reuse is the granule of release. Only components Design PrinciplesКлассы в пакете используются совместно. Если используется один класс из пакета, Design PrinciplesКлассы в пакете должны быть связаны одинаковой причиной их изменения. Изменение Design PrinciplesНе должно быть взаимной зависимости между пакетами, только односторонняя.ADP: Acyclic Dependenciesvs Design PrinciplesЗависимости между пакетами должны быть в сторону более стабильного. Пакет должен Design PrinciplesСамые стабильные пакеты должны быть самыми абстрактными. Нестабильные пакеты должны быть Design PrinciplesREP : Reuse/Release EquivalenceCRP : Common ReuseCCP : Common ClosureADP : Design PrinciplesTDA – стиль ООП, при котором объектА сигнализирует объектуБ выполнить его Design PrinciplesОбъекты берут на себя сфокусированные ответственности и делегируют остальные ответственности другим Design PrinciplesРазделяйте ответственности по сфокусированным классамaka Single Responsibility Principle «Класс должен иметь Design PrinciplesSOC : Separation Of Concerns План семинараВыводы ВопросыБуду рад ответить на Ваши вопросыСсылка на оценочную форму семинара:http://www.luxoft-training.ru/events/vote Учебный Центр LuxoftУЦ Luxoft предлагает более 200 курсов и тренингов по различным Конференции УЦ LuxoftКонференции (www.soft-labs.ru): 26 сентября, Киев: TEST Labs 2009, программа сформирована, Ближайшие занятия в ШколахРасписание:Класс руководителя группы разработки. Основные курсы (24.08.2009-15.09.2009)Класс менеджера проектов. Базовые правила и принципы проектирования ПОЕвгений КривошеевEKrivosheev@luxoft.com
Слайды презентации

Слайд 2 О вашем инструкторе
Имя: Евгений Кривошеев
Статусы: SCJP, SCWCD, SCBCD, BEA WLS

О вашем инструктореИмя: Евгений КривошеевСтатусы: SCJP, SCWCD, SCBCD, BEA WLS CA, IBM WAS CAКонтакты: EKrivosheev@luxoft.com

CA, IBM WAS CA
Контакты: EKrivosheev@luxoft.com

Слайд 3 Цели семинара
Семинар призван систематизировать базовые правила и принципы

Цели семинараСеминар призван систематизировать базовые правила и принципы проектирования ПОПредставленные базовые

проектирования ПО
Представленные базовые принципы необходимы для понимания более сфокусированных

техник и приемов - рефакторинга и шаблонов проектирования

Слайд 4 Цели семинара
Данный семинар – вводный, ~ 3 мин

Цели семинараДанный семинар – вводный, ~ 3 мин на принцип или

на принцип или правило
В дальнейшем будет разработан полноценный курс

Слайд 5 Необходимая подготовка
Иметь опыт разработки на одном из ООП-языков

Необходимая подготовкаИметь опыт разработки на одном из ООП-языков программированияПонимать ключевые концепции ООПСлушатели должны:

программирования
Понимать ключевые концепции ООП
Слушатели должны:

Слайд 6 Организация обучения
Время начала и конца занятий
Перерывы

Организация обученияВремя начала и конца занятийПерерывы

Слайд 7 Конференции УЦ Luxoft
Конференции (www.soft-labs.ru):
26 сентября, Киев: TEST

Конференции УЦ LuxoftКонференции (www.soft-labs.ru): 26 сентября, Киев: TEST Labs 2009, программа

Labs 2009, программа сформирована, регистрация участников
17 ноября, Москва: Req

Labs 2009, открыта регистрация докладчиков
15 декабря, Москва: Arch Labs 2009, открыта регистрация докладчиков

Слайд 8 Ближайшие занятия в Школах
Расписание:
Класс руководителя группы разработки. Основные

Ближайшие занятия в ШколахРасписание:Класс руководителя группы разработки. Основные курсы (24.08.2009-15.09.2009)Класс менеджера

курсы (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

Слайд 9 План семинара

План семинара

Слайд 10 Введение
Наследование
Полиморфизм

Ключевые понятия ООП-проектирования (общеизвестные)

ВведениеНаследованиеПолиморфизмКлючевые понятия ООП-проектирования (общеизвестные)

Слайд 11 Введение
Responsibility (ответственность)
Intention (намерение)
Coupling (связность)
Cohesion (сцепленность, сфокусированность)
Granularity (гранулярность, детальность)
Ключевые

ВведениеResponsibility (ответственность)Intention (намерение)Coupling (связность)Cohesion (сцепленность, сфокусированность)Granularity (гранулярность, детальность)Ключевые понятия ООП-проектирования (менее известные)

понятия ООП-проектирования (менее известные)

Слайд 12 Введение
Ответственность – решаемая классом задача из предметной области
Функциональная

ВведениеОтветственность – решаемая классом задача из предметной областиФункциональная задачаИнкапсуляция данныхЧаще этот термин применяется для классовResponsibility

задача
Инкапсуляция данных
Чаще этот термин применяется для классов

Responsibility

Слайд 13 Введение
Намерение – решаемая разработчиком задача
Чаще этот термин применяется

ВведениеНамерение – решаемая разработчиком задачаЧаще этот термин применяется для методовIntention

для методов

Intention

Слайд 14 Введение
Связность – метрика, характеризующая степень зависимости классов друг

ВведениеСвязность – метрика, характеризующая степень зависимости классов друг от другаLoosely coupled

от друга
Loosely coupled vs. Tightly coupled
Классы могут быть связаны

(coupled) различными образами:
Зависимые
По управлению
По данным

Coupling

Слайд 15 Введение
Сцепленность (Сфокусированность) – метрика, характеризующая узость ответственности класса
Low

ВведениеСцепленность (Сфокусированность) – метрика, характеризующая узость ответственности классаLow cohesion vs. High

cohesion vs. High cohesion
Классы могут иметь различную сфокусированность (cohesion):
По

функциональности
По данным

Cohesion

Слайд 16 Введение
Гранулированность (Детальность) – метрика, характеризующая способ реализации намерений
Fine-grained

ВведениеГранулированность (Детальность) – метрика, характеризующая способ реализации намеренийFine-grained vs. Coarse-grainedЧаще этот

vs. Coarse-grained
Чаще этот термин применяется для интерфейсов, где намерение

выражается методом

Granularity

Слайд 17 Введение
Наследование
Делегирование
Инструменты code reuse в ООП

ВведениеНаследованиеДелегированиеИнструменты code reuse в ООП

Слайд 18 Введение
Brian Foote and William F. Opdyke. Lifecycle and

ВведениеBrian Foote and William F. Opdyke. Lifecycle and refactoring patterns that

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

Литературные источники семинара

Слайд 19 План семинара

План семинара

Слайд 20 Design Rules
Литературные источники

Design RulesЛитературные источники

Слайд 21 Design Rules
Design Rules
http://www.laputan.org/drc/drc.html

Design RulesDesign Ruleshttp://www.laputan.org/drc/drc.html

Слайд 22 Design Rules
В дальнейшем обсуждении мы рассмотрим не дословный

Design RulesВ дальнейшем обсуждении мы рассмотрим не дословный перевод правил проектирования,

перевод правил проектирования, а расширенные современные трактовки
Важно помнить, что

эти правила хоть и распространенные, но контекстные, т.е. их применимость следует обосновывать

Design Rules

Слайд 23 Design Rules
Используйте непротиворечивые имена методов [и свойств]
Непротиворечивость здесь

Design RulesИспользуйте непротиворечивые имена методов [и свойств]Непротиворечивость здесь – это одинаковые

– это одинаковые имена для одинаковых намерений
В книге [MF]

есть аналогичный smell/refactoring

DR1. Use Consistent Names
DR1. Recursion introduction

Слайд 24 Design Rules
Избегайте смешивания бизнес-логики и логики выбора/ветвления
В книге

Design RulesИзбегайте смешивания бизнес-логики и логики выбора/ветвленияВ книге [MF] есть аналогичный smell/refactoringDR2. Eliminate Case Analysis

[MF] есть аналогичный smell/refactoring

DR2. Eliminate Case Analysis

Слайд 25 Design Rules
Уменьшайте число аргументов/параметров
В книге [MF] есть аналогичный

Design RulesУменьшайте число аргументов/параметровВ книге [MF] есть аналогичный smell/refactoringDR3. Reduce The Number Of Arguments

smell/refactoring

DR3. Reduce The Number Of Arguments

Слайд 26 Design Rules
Уменьшайте объем методов
В книге [MF] есть аналогичный

Design RulesУменьшайте объем методовВ книге [MF] есть аналогичный smell/refactoringDR4. Reduce The Size Of Methods

smell/refactoring


DR4. Reduce The Size Of Methods

Слайд 27 Иерархию наследования стоит проектировать глубокой и узкой



Design Rules
DR5.

Иерархию наследования стоит проектировать глубокой и узкойDesign RulesDR5. Class Hierarchies Should Be Deep And Narrowдалее

Class Hierarchies Should Be Deep And Narrow
далее

Слайд 28 Design Rules
DR5. Class Hierarchies Should Be Deep And

Design RulesDR5. Class Hierarchies Should Be Deep And Narrowvs

Narrow
vs

Слайд 29 Design Rules
На вершине иерархии наследования стоит размещать абстракцию
DR6.

Design RulesНа вершине иерархии наследования стоит размещать абстракциюDR6. The Top Of

The Top Of The Class Hierarchy Should Be Abstract
vs

Слайд 30 Design Rules
Стоит минимизировать прямой доступ к переменным классов

Design RulesСтоит минимизировать прямой доступ к переменным классов и экземпляровEncapsulation aka

и экземпляров
Encapsulation aka Hiding
В книге [MF] есть аналогичный smell/refactoring

DR7.

Minimize Access to Variables

Слайд 31 Design Rules
Наследники должны быть специализациями базовых классов
Специализация –

Design RulesНаследники должны быть специализациями базовых классовСпециализация – отношение «IS-A», «является»В

отношение «IS-A», «является»
В книге [MF] есть аналогичный smell/refactoring (Refused

Bequest)

DR8. Subclasses Should Be Specializations

Слайд 32 Design Rules
Разбивайте большие классы
В книге [MF] есть аналогичный

Design RulesРазбивайте большие классыВ книге [MF] есть аналогичный smell/refactoringDR9. Split Large Classes

smell/refactoring


DR9. Split Large Classes

Слайд 33 Design Rules
В случае серьезной разницы в реализации метода

Design RulesВ случае серьезной разницы в реализации метода двумя «братьями» стоит

двумя «братьями» стоит задуматься о целесообразности описания этого метода

в их «отце»
Потенциально можно вынести этот метод в иной класс (делегировать)

DR10. Factor Implementation Differences Into Subcomponents

Слайд 34 Design Rules
Разделяйте несвязанные методы
Связь:
по управлению
по данным
В книге [MF]

Design RulesРазделяйте несвязанные методыСвязь:по управлениюпо даннымВ книге [MF] есть аналогичный smell/refactoringDR11.

есть аналогичный smell/refactoring
DR11. Separate Methods That Do Not Communicate

Слайд 35 Design Rules
Делегируйте
Inheritance-based framework vs component-based framework – где

Design RulesДелегируйтеInheritance-based framework vs component-based framework – где ниже связность?DR12. Send

ниже связность?

DR12. Send Messages To Components Instead Of To

Self

Слайд 36 Design Rules
Передавайте параметры явно
Варианты неявной передачи:
глобальные переменные
состояние
внешние источники

Design RulesПередавайте параметры явноВарианты неявной передачи:глобальные переменныесостояниевнешние источники данныхВызов метода, результат

данных
Вызов метода, результат которого зависит только от входных параметров

- идемпотентный

DR13. Reduce Implicit Parameter Passing

Слайд 37 План семинара

План семинара

Слайд 38 Вопросы
Буду рад ответить на Ваши вопросы

ВопросыБуду рад ответить на Ваши вопросы

Слайд 39 План семинара

План семинара

Слайд 40 Design Principles
Литературные источники

Design PrinciplesЛитературные источники

Слайд 41 Design Principles
Design Principles
DRY : Don’t Repeat Yourself
SCP

Design PrinciplesDesign PrinciplesDRY : Don’t Repeat Yourself SCP : Speaking CodeOCP

: Speaking Code
OCP : Open/Closed
LSP : Liskov Substitution
DIP :

Dependency Inversion
ISP : 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
Минимизируйте повторение кода для снижения затрат на

Design PrinciplesМинимизируйте повторение кода для снижения затрат на поддержкуaka Single Point

поддержку
aka Single Point of Truth or Single Point of

Maintenance
В книге [MF] есть аналогичный smell/refactoring

DRY: Don’t Repeat Yourself

Слайд 43 Design Principles
Код должен явно и однозначно отражать намерение
В

Design PrinciplesКод должен явно и однозначно отражать намерениеВ книге [MF] есть аналогичный smell/refactoringSCP: Speaking Code

книге [MF] есть аналогичный smell/refactoring

SCP: Speaking Code

Слайд 44 Design Principles
Программные сущности (классы, модули, функции) должны быть

Design PrinciplesПрограммные сущности (классы, модули, функции) должны быть открыты для расширения

открыты для расширения и закрыты для изменения
«Открыты для расширения»

- возможно расширять и изменять поведение приложения при изменении требований
«Закрыты для изменения» - расширение поведения не приводит к изменению исходного или бинарного кода

OCP: Open/Closed


далее

Слайд 45 Design Principles
Принцип OCP используется в двух контекстах его

Design PrinciplesПринцип OCP используется в двух контекстах его реализации:Dr. Bertrand Meyer's

реализации:
Dr. Bertrand Meyer's Open/Closed Principle «Написанная реализация класса модифицируется только

для исправления ошибок, новые ответственности или изменение существующих потребует создание нового класса, возможно, наследника. Этот новый класс не обязан реализовать тот же интерфейс.»
Polymorphic Open/Closed Principle Более современная версия. «Множество реализаций классов можно использовать полиморфно, через один и тот же интерфейс.» Здесь зафиксирована интерфейсная часть, а реализация вариативна.
См. так же «Protected Variation»

OCP: Open/Closed


далее

Слайд 46 Design Principles
OCP: Open/Closed

Design PrinciplesOCP: Open/Closed

Слайд 47 Design Principles
Существует два базовых определения:
Barbara Liskov «В коде приложения

Design PrinciplesСуществует два базовых определения:Barbara Liskov «В коде приложения класс всегда

класс всегда можно заменить его наследником»
Bertrand Meyer ("Design-by-Contract" formulation) «Наследники

должны соблюдать контракт предка»

LSP: Liskov Substitution


далее

Слайд 48 Design Principles
LSP: Liskov Substitution

Design PrinciplesLSP: Liskov Substitution

Слайд 49 Design Principles
Высокоуровневые модули не должны зависеть от низкоуровневых.

Design PrinciplesВысокоуровневые модули не должны зависеть от низкоуровневых. И те, и

И те, и другие должны зависеть от абстракций.
Абстракции не

должны зависеть от деталей. Детали должны зависеть от абстракции.

DIP: Dependency Inversion


далее

Слайд 50 Design Principles
С помощью абстракций детали системы изолируются друг

Design PrinciplesС помощью абстракций детали системы изолируются друг от другаЛегко менять

от друга
Легко менять детали реализации без модификации высокоуровневой логики
Шаблоны,

с помощью которых реализуется принцип DIP:
Plug-in, [A] Factory [M], Service Locator, Inversion of Control, Dependency Injection

DIP: Dependency Inversion


далее

Слайд 51 Design Principles
DIP: Dependency Inversion

далее
vs

Design PrinciplesDIP: Dependency Inversionдалееvs

Слайд 52 Design Principles
DIP: Dependency Inversion

далее

Design PrinciplesDIP: Dependency Inversionдалее

Слайд 53 Design Principles
Inversion Of Control
Принцип инверсии управления потоком выполнения

Design PrinciplesInversion Of ControlПринцип инверсии управления потоком выполнения по сравнению с

по сравнению с процедурным программированием
Основа всех каркасов (frameworks)
aka Hollywood

Principle
Dependency Injection
Шаблон проектирования
Не мы сами получаем необходимые объекты, а внешняя среда нам их передает

DIP → IoC → Dependency Injection

Слайд 54 Design Principles
Не стоит заставлять клиентов зависеть от ненужных

Design PrinciplesНе стоит заставлять клиентов зависеть от ненужных им интерфейсовВместо одного

им интерфейсов
Вместо одного многофункционального интерфейса лучше выделить несколько узкоспециальных
ISP:

Interface Segregation


далее

Слайд 55 Design Principles
ISP: Interface Segregation

Design PrinciplesISP: Interface Segregation

Слайд 56 Design Principles
The granule of reuse is the granule

Design PrinciplesThe granule of reuse is the granule of release. Only

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
Классы в пакете используются совместно. Если используется

Design PrinciplesКлассы в пакете используются совместно. Если используется один класс из

один класс из пакета, считается что используются все.
Здесь использование

– многократное использование при дальнейшей разработке

CRP: Common Reuse

Слайд 58 Design Principles
Классы в пакете должны быть связаны одинаковой

Design PrinciplesКлассы в пакете должны быть связаны одинаковой причиной их изменения.

причиной их изменения. Изменение пакета (одного из классов) касается

всех классов в нем.

CCP: Common Closure

Слайд 59 Design Principles
Не должно быть взаимной зависимости между пакетами,

Design PrinciplesНе должно быть взаимной зависимости между пакетами, только односторонняя.ADP: Acyclic Dependenciesvs

только односторонняя.


ADP: Acyclic Dependencies
vs

Слайд 60 Design Principles
Зависимости между пакетами должны быть в сторону

Design PrinciplesЗависимости между пакетами должны быть в сторону более стабильного. Пакет

более стабильного. Пакет должен зависеть только от более стабильного

пакета, чем он сам.
Стабильность модуля, класса или пакета – степень сложности его изменений
Стабильные классы – независимые классы (незачем менять) или сильнозависимые (множество причин не менять)

SDP: Stable Dependencies

Слайд 61 Design Principles
Самые стабильные пакеты должны быть самыми абстрактными.

Design PrinciplesСамые стабильные пакеты должны быть самыми абстрактными. Нестабильные пакеты должны

Нестабильные пакеты должны быть конкретными. Степень абстракции пакета должна

зависеть от его стабильности.

SAP: Stable Abstractions

Слайд 62 Design Principles
REP : Reuse/Release
Equivalence
CRP : Common Reuse
CCP

Design PrinciplesREP : Reuse/Release EquivalenceCRP : Common ReuseCCP : Common ClosureADP

: Common Closure
ADP : Acyclic Dependencies
SDP : Stable Dependencies
SAP

: Stable Abstractions

Слайд 63 Design Principles
TDA – стиль ООП, при котором объектА

Design PrinciplesTDA – стиль ООП, при котором объектА сигнализирует объектуБ выполнить

сигнализирует объектуБ выполнить его ответственность, вместо того, чтобы что-либо

спрашивать у него и выполнять ответственность самому

TDA: Tell, Don’t Ask


далее

Слайд 64 Design Principles
Объекты берут на себя сфокусированные ответственности и

Design PrinciplesОбъекты берут на себя сфокусированные ответственности и делегируют остальные ответственности

делегируют остальные ответственности другим объектам
ООП vs Процедурный стиль
См. так

же «Low Of Demeter»

TDA: Tell, Don’t Ask

Слайд 65 Design Principles
Разделяйте ответственности по сфокусированным классам
aka Single Responsibility

Design PrinciplesРазделяйте ответственности по сфокусированным классамaka Single Responsibility Principle «Класс должен

Principle «Класс должен иметь только одну причину изменения»
SOC: Separation Of

Concerns


далее

Слайд 66 Design Principles
SOC : Separation Of Concerns

Design PrinciplesSOC : Separation Of Concerns

Слайд 67 План семинара
Выводы

План семинараВыводы

Слайд 68 Вопросы
Буду рад ответить на Ваши вопросы

Ссылка на оценочную

ВопросыБуду рад ответить на Ваши вопросыСсылка на оценочную форму семинара:http://www.luxoft-training.ru/events/vote

форму семинара:
http://www.luxoft-training.ru/events/vote

Слайд 69 Учебный Центр Luxoft
УЦ Luxoft предлагает более 200 курсов

Учебный Центр LuxoftУЦ Luxoft предлагает более 200 курсов и тренингов по

и тренингов по различным направлениям промышленной разработки ПО
Наши инструкторы

– практики, готовые передать свою экспертизу

http://luxoft-training.ru

Слайд 70 Конференции УЦ Luxoft
Конференции (www.soft-labs.ru):
26 сентября, Киев: TEST

Конференции УЦ LuxoftКонференции (www.soft-labs.ru): 26 сентября, Киев: TEST Labs 2009, программа

Labs 2009, программа сформирована, регистрация участников
17 ноября, Москва: Req

Labs 2009, открыта регистрация докладчиков
15 декабря, Москва: Arch Labs 2009, открыта регистрация докладчиков

Слайд 71 Ближайшие занятия в Школах
Расписание:
Класс руководителя группы разработки. Основные

Ближайшие занятия в ШколахРасписание:Класс руководителя группы разработки. Основные курсы (24.08.2009-15.09.2009)Класс менеджера

курсы (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

  • Имя файла: bazovye-pravila-i-printsipy-proektirovaniya.pptx
  • Количество просмотров: 166
  • Количество скачиваний: 0
- Предыдущая Экология в Казахстане
Следующая - Конный спорт

Похожие презентации

Мировой экономический кризис 1929-1933 Мировой экономический кризис 1929-1933 154
Механизм рассмотрения и утверждения федерального бюджета на очередной финансовый год Механизм рассмотрения и утверждения федерального бюджета на очередной финансовый год 117
Event-менеджмент Event-менеджмент 158
Медицинские организации в сфере обязательного медицинского страхования Медицинские организации в сфере обязательного медицинского страхования 116
Содержание, принципы и цели маркетинга Содержание, принципы и цели маркетинга 119
Появление денег Появление денег 161
Анализ финансовой устойчивости предприятия: показатели, методика оценки Анализ финансовой устойчивости предприятия: показатели, методика оценки 190
Как возникла экономика Как возникла экономика 147
Сравнительный анализ стран с переходной экономикой Сравнительный анализ стран с переходной экономикой 128
Неравенство доходов в обществе Неравенство доходов в обществе 146
Налог Налог 139
Внешние и внутренние угрозы в высокотехнологичном секторе економике Внешние и внутренние угрозы в высокотехнологичном секторе економике 131
Мировая экономика Мировая экономика 142
Финансовый анализ предприятия Финансовый анализ предприятия 158
Региональные особенности хозяйствования федеральных округов Региональные особенности хозяйствования федеральных округов 133
Развитие ключевых компетентностей младших школьников на уроках экономики Развитие ключевых компетентностей младших школьников на уроках экономики 130
Банковская и кредитная система Банковская и кредитная система 197
Экономическое районирование и административно-территориальное устройство РФ Экономическое районирование и административно-территориальное устройство РФ 137
The Accountant’s Role in the Organization The Accountant’s Role in the Organization 147
Построение индикаторных линий, расчет коэффициента продуктивности Построение индикаторных линий, расчет коэффициента продуктивности 128
Генеральное соглашение по торговле услугами2 Генеральное соглашение по торговле услугами2 140
Оценка емкости рынка Оценка емкости рынка 115
Маркетинг социальных услуг Маркетинг социальных услуг 179
Time value of money Time value of money 137
Экономическая культура Экономическая культура 153
Выпуск денег в хозяйственный оборот Выпуск денег в хозяйственный оборот 122
Состояние международной валютной системы Состояние международной валютной системы 112
Государственная поддержка социально-ориентированных проектов НКО, работающих в сфере этнокультурного развития Государственная поддержка социально-ориентированных проектов НКО, работающих в сфере этнокультурного развития 145
Бинарный урок (экономика + физика) по теме Арктика – стратегия будущегоБинарный урок (экономика + физика) по теме Арктика – стратегия будущего Бинарный урок (экономика + физика) по теме Арктика – стратегия будущегоБинарный урок (экономика + физика) по теме Арктика – стратегия будущего 143
Неомарксистсткая экономическая социология: анализ перехода от фордизма к постфордизму Неомарксистсткая экономическая социология: анализ перехода от фордизма к постфордизму 140