чистый код паттерны проектирования Олег Антонов Senior Web Developer MobiDev Corporation

План семинара ООП и Чистый код Паттерны проектирования Преимущества и недостатки паттернов Применение паттернов Подведение итогов

Признаки плохого кода дублирование кода; длинный метод; большой класс; длинный список параметров; избыточные временные переменные; классы данных; несгруппированные данные.

Причины возникновения плохого кода Частые изменения в требованиях, противоречащие исходной архитектуре; недостаточно времени сделать работу качественно; глупый менеджер/начальник/заказчик и т.д. Ваш вариант.

Настоящие причины возникновения плохого кода Непрофессионализм Лень

Закон Леблана «Потом равносильно никогда»

Чистый код «Я люблю, чтобы мой код был элегантным и эффективным. Логика должна быть достаточно прямолинейной, чтобы ошибкам было трудно спрятаться; зависимости – минимальными, чтобы упростить сопровождение; обработка ошибок – полной, в соответствии с выбранной стратегией; а производительность – близкой к оптимальной, чтобы не искушать людей загрязнять код беспринципными оптимизациями.» Бьерн Страуструп автор языка C++

Приемы чистого кода Именование переменных; правильная работа с функциями; комментирование кода; форматирование; обработка ошибок; тестирование.

Объектно-ориентированное проектирование Проектирование объектно-ориентированных программ – нелегкое дело, а если их нужно использовать повторно, то все становится еще сложнее. Эрих Гамма Автор книги Design Patterns

Правильный дизайн Правильный дизайн – это гибкий и пригодный для повторного использования дизайн. Он должен, с одной стороны, соответствовать решаемой задаче, с другой быть общим, чтобы учесть все требования, которые могут возникнуть в будущем.

Паттерны проектирования Паттерн проектирования повторимая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста.

Классификация паттернов Порождающие (Creational) Структурные (Structural) Поведенческие (Behavioral)

Порождающие паттерны Порождающие паттерны паттерны проектирования, которые абстрагируют процесс инстанцирования. Они позволяют сделать систему независимой от способа создания, композиции и представления объектов. Паттерн, порождающий классы, использует наследование, чтобы изменять инстанцируемый класс, а паттерн, порождающий объекты, делегирует инстанцирование другому объекту.

Виды порождающих паттернов Абстрактная фабрика (Abstract Factory) Строитель (Builder) Фабричный метод (Factory Method) Прототип (Prototype) Одиночка (Singleton)

Абстрактная фабрика Абстрактная фабрика паттерн, порождающий объекты. Предоставляет интерфейс для создания семейств взаимосвязанных или взаимозависимых объектов не специфицируя их конкретных классов.

Абстрактная фабрика

Плюсы и минусы Изолирует конкретные классы; упрощает замену семейств продуктов; гарантирует сочетаемость продуктов; поддержать новый вид продуктов трудно.

Структурные паттерны Структурные паттерны паттерны проектирования, в которых рассматривается вопрос о том, как из классов и объектов образуются более крупные структуры.

Виды структурных паттернов Адаптер (Adapter) Мост (Bridge) Компоновщик (Composite) Декоратор (Decorator) Фасад (Facade) Приспособленец (Flyweight) Заместитель (Proxy)

Компоновщик Компоновщик паттерн проектирования, относится к структурным паттернам, объединяет объекты в древовидную структуру для представления иерархии от частного к целому. Компоновщик позволяет клиентам обращаться к отдельным объектам и к группам объектов одинаково.

Компоновщик

Плюсы и минусы Определяет иерархии классов, состоящие из примитивных и составных объектов; упрощает архитектуру клиента; облегчает добавление новых видов компонентов; способствует созданию общего дизайна.

Поведенческие паттерны Поведенческие паттерны паттерны проектирования, определяющие алгоритмы и способы реализации взаимодействия различных объектов и классов.

Виды поведенческих паттернов Цепочка обязанностей (Chain of Responsibility) Команда (Command) Интерпретатор (Interpreter) Итератор (Iterator) Посредник (Mediator) Хранитель (Memento) Наблюдатель (Observer) Состояние (State) Стратегия (Strategy) Шаблонный метод (Template Method) Посетитель (Visitor)

Наблюдатель Наблюдатель поведенческий шаблон проектирования. Определяет зависимость типа «один ко многим» между объектами таким образом, что при изменении состояния одного объекта все зависящие от него оповещаются об этом событии.

Наблюдатель

Плюсы и минусы Абстрактная связанность субъекта и наблюдателя; поддержка широковещательных коммуникаций; неожиданные обновления.

Инверсия управления Инверсия управления (Inversion of Control) принцип программирования, который уменьшает связанность между программными компонентами.

Принципы инверсии управления Модули верхнего уровня не должны зависеть от модулей нижнего уровня. Оба типа модулей должны зависеть от абстракций; абстракция не должна зависеть от реализации. Реализация должна зависеть от абстракции.

Внедрение зависимости Внедрение зависимости (Dependency Injection) процесс предоставления внешней зависимости программному компоненту. Является специфичной формой «инверсии управления», где изменение порядка связи является путём получения необходимой зависимости.

Преимущества внедрения зависимости Ослабление соединения между классами; создание кода, который лучше поддается проверке; упрощение тестирования.

Виды внедрений зависимости Constructor injection Setter injection Interface injection

Без внедрения зависимости

Constructor Injection

Setter Injection

IoC-Контейнер IoC-контейнер это класс, библиотека или фреймворк, который позволит упростить и автоматизировать написание кода с использованием подхода инверсии управления.

IoC-Контейнер

Вывод Применяйте паттерны проектирования

Заблуждение 1 Паттерны гарантируют возможность повторного использования программного обеспечения, повышение производительности, отсутствие разногласий и т.д.

Заблуждение 2 Паттерны предоставляют готовые архитектурные решения

Заблуждение 3 Паттерны предназначены для объектно-ориентированного проектирования и реализации

Преимущества паттернов проектирования Использование предыдущего опыта экспертов. Улучшение взаимопонимания разработчиков. Альтернатива документации приложений. Упрощение реструктуризации системы.

Спасибо за внимание