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

Имя: Евгений Кривошеев Имя: Евгений Кривошеев Статусы: SCJP, SCWCD, SCBCD, BEA WLS CA, IBM WAS CA Контакты: [email protected]

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

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

Иметь опыт разработки на одном из ООП-языков программирования Иметь опыт разработки на одном из ООП-языков программирования Понимать ключевые концепции ООП

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

Конференции (www.soft-labs.ru): Конференции (www.soft-labs.ru): 26 сентября, Киев: TEST Labs 2009, программа сформирована, регистрация участников 17 ноября, Москва: Req Labs 2009, открыта регистрация докладчиков 15 декабря, Москва: Arch Labs 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

Наследование Наследование Полиморфизм

Responsibility (ответственность) Responsibility (ответственность) Intention (намерение) Coupling (связность) Cohesion (сцепленность, сфокусированность) Granularity (гранулярность, детальность)

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

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

Связность – метрика, характеризующая степень зависимости классов друг от друга Связность – метрика, характеризующая степень зависимости классов друг от друга Loosely coupled vs. Tightly coupled Классы могут быть связаны (coupled) различными образами: Зависимые По управлению По данным

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

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

Наследование Наследование Делегирование

Brian Foote and William F. Opdyke. Lifecycle and refactoring patterns that support evolution and reuse, 1995 (отдельно и в рамках книги Pattern Languages of Program Design vol. 1) 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

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

Используйте непротиворечивые имена методов [и свойств] Используйте непротиворечивые имена методов [и свойств] Непротиворечивость здесь – это одинаковые имена для одинаковых намерений В книге [MF] есть аналогичный smell/refactoring

Избегайте смешивания бизнес-логики и логики выбора/ветвления Избегайте смешивания бизнес-логики и логики выбора/ветвления В книге [MF] есть аналогичный smell/refactoring

Уменьшайте число аргументов/параметров Уменьшайте число аргументов/параметров В книге [MF] есть аналогичный smell/refactoring

Уменьшайте объем методов Уменьшайте объем методов В книге [MF] есть аналогичный smell/refactoring

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

На вершине иерархии наследования стоит размещать абстракцию На вершине иерархии наследования стоит размещать абстракцию

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

Наследники должны быть специализациями базовых классов Наследники должны быть специализациями базовых классов Специализация – отношение «IS-A», «является» В книге [MF] есть аналогичный smell/refactoring (Refused Bequest)

Разбивайте большие классы Разбивайте большие классы В книге [MF] есть аналогичный smell/refactoring

В случае серьезной разницы в реализации метода двумя «братьями» стоит задуматься о целесообразности описания этого метода в их «отце» В случае серьезной разницы в реализации метода двумя «братьями» стоит задуматься о целесообразности описания этого метода в их «отце» Потенциально можно вынести этот метод в иной класс (делегировать)

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

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

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

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

Минимизируйте повторение кода для снижения затрат на поддержку Минимизируйте повторение кода для снижения затрат на поддержку aka Single Point of Truth or Single Point of Maintenance В книге [MF] есть аналогичный smell/refactoring

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

Программные сущности (классы, модули, функции) должны быть открыты для расширения и закрыты для изменения Программные сущности (классы, модули, функции) должны быть открыты для расширения и закрыты для изменения «Открыты для расширения» - возможно расширять и изменять поведение приложения при изменении требований «Закрыты для изменения» - расширение поведения не приводит к изменению исходного или бинарного кода

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

Существует два базовых определения: Существует два базовых определения: Barbara Liskov «В коде приложения класс всегда можно заменить его наследником» Bertrand Meyer ("Design-by-Contract" formulation) «Наследники должны соблюдать контракт предка»

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

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

Inversion Of Control Inversion Of Control Принцип инверсии управления потоком выполнения по сравнению с процедурным программированием Основа всех каркасов (frameworks) aka Hollywood Principle Dependency Injection Шаблон проектирования Не мы сами получаем необходимые объекты, а внешняя среда нам их передает

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

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 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 и ряд следующих принципов – макропринципы организации разработки и пакетирования кода

Классы в пакете используются совместно. Если используется один класс из пакета, считается что используются все. Классы в пакете используются совместно. Если используется один класс из пакета, считается что используются все. Здесь использование – многократное использование при дальнейшей разработке

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

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

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

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

TDA – стиль ООП, при котором объектА сигнализирует объектуБ выполнить его ответственность, вместо того, чтобы что-либо спрашивать у него и выполнять ответственность самому TDA – стиль ООП, при котором объектА сигнализирует объектуБ выполнить его ответственность, вместо того, чтобы что-либо спрашивать у него и выполнять ответственность самому

Объекты берут на себя сфокусированные ответственности и делегируют остальные ответственности другим объектам Объекты берут на себя сфокусированные ответственности и делегируют остальные ответственности другим объектам ООП vs Процедурный стиль См. так же «Low Of Demeter»

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

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

УЦ Luxoft предлагает более 200 курсов и тренингов по различным направлениям промышленной разработки ПО УЦ Luxoft предлагает более 200 курсов и тренингов по различным направлениям промышленной разработки ПО Наши инструкторы – практики, готовые передать свою экспертизу

Конференции (www.soft-labs.ru): Конференции (www.soft-labs.ru): 26 сентября, Киев: TEST Labs 2009, программа сформирована, регистрация участников 17 ноября, Москва: Req Labs 2009, открыта регистрация докладчиков 15 декабря, Москва: Arch Labs 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