SugarCRM, Intetics
- Главная
- Разное
- Дизайн
- Бизнес и предпринимательство
- Аналитика
- Образование
- Развлечения
- Красота и здоровье
- Финансы
- Государство
- Путешествия
- Спорт
- Недвижимость
- Армия
- Графика
- Культурология
- Еда и кулинария
- Лингвистика
- Английский язык
- Астрономия
- Алгебра
- Биология
- География
- Детские презентации
- Информатика
- История
- Литература
- Маркетинг
- Математика
- Медицина
- Менеджмент
- Музыка
- МХК
- Немецкий язык
- ОБЖ
- Обществознание
- Окружающий мир
- Педагогика
- Русский язык
- Технология
- Физика
- Философия
- Химия
- Шаблоны, картинки для презентаций
- Экология
- Экономика
- Юриспруденция
Solid - принципы с примерами PHP презентация
Содержание
- 1. Solid - принципы с примерами PHP
- 2. Что такое SOLID принцины? Single responsibility Open-closed Liskov substitution Interface segregation Dependency inversion
- 3. Single Responsibility Принцип единой ответственности "На каждый
- 4. Single Responsibility Плохой код
- 5. Single Responsibility Почему плохой код?
- 6. Single Responsibility Хороший код
- 7. Single Responsibility Реальный пример
- 8. Open-Closed Принцип открытости/закрытости "Программные сущности должны быть
- 9. Open-Closed Плохой код
- 10. Open-Closed Почему плохой код? Плохо расширяемый
- 11. Open-Closed Хороший код
- 12. Open-Closed Хороший код
- 13. Symfony Framework Open-Closed Реальный пример
- 14. Open-Closed Реальный пример - Улучшенный
- 15. Liskov Substitution Принцип подстановки Лисков «Функции,
- 16. Liskov Substitution Плохой код (пока ещё хороший)
- 17. Liskov Substitution Плохой код
- 18. Liskov Substitution Почему плохой код? При
- 19. Liskov Substitution Хороший код
- 20. Liskov Substitution Плохой код
- 21. Liskov Substitution Хороший код
- 22. Liskov Substitution Реальный пример Symfony 2 Framework
- 23. Interface Segregation Принцип разделения интерфейса «Много
- 24. Interface Segregation Плохой код
- 25. Interface Segregation Почему плохой код? Интерфейс
- 26. Interface Segregation Хороший код
- 27. Interface Segregation Реальный пример Laravel 5 Framework
- 28. Dependency Inversion Принцип инверсии зависимостей «Зависимости
- 29. Dependency Inversion Плохой код
- 30. Dependency Inversion Почему плохой код? Зависимости
- 31. Dependency Inversion Хороший код
- 32. Dependency Inversion Реальный пример Laravel 5 Framework
- 33. Заключение SOLID — не панацея
- 34. Вопросы?
Что такое SOLID принцины? Single responsibility Open-closed Liskov substitution Interface segregation Dependency inversion
Слайд 2Что такое SOLID принцины?
Single responsibility
Open-closed
Liskov substitution
Interface segregation
Dependency inversion
Слайд 3Single Responsibility
Принцип единой ответственности
"На каждый объект должна быть возложена одна единственная
обязанность"
Конкретный класс должен решать конкретную задачу — ни больше, ни меньше.
Конкретный класс должен решать конкретную задачу — ни больше, ни меньше.
Слайд 5Single Responsibility
Почему плохой код?
Такой код сложнее в сопровождении.
Каждая ответственность — причина
для изменений, а изменения потенциально опасны.
Каскадные изменения тесносвязанных ответственностей.
Каскадные изменения тесносвязанных ответственностей.
Слайд 7Single Responsibility
Реальный пример
PHPMailer — класс содержит 3925 строк кода и порядка
80 публичных методов
CodeIgniter
CodeIgniter
Слайд 8Open-Closed
Принцип открытости/закрытости
"Программные сущности должны быть открыты для расширения, но закрыты для
модификации"
Все классы, функции и т.д. должны проектироваться так, чтобы для изменения или расширения их поведения, нам не нужно было изменять их исходный код.
Все классы, функции и т.д. должны проектироваться так, чтобы для изменения или расширения их поведения, нам не нужно было изменять их исходный код.
Слайд 10Open-Closed
Почему плохой код?
Плохо расширяемый код
Его сложно повторно использовать.
Необходимо менять OrderCalculator для
новых Order
Слайд 15Liskov Substitution
Принцип подстановки Лисков
«Функции, которые используют базовый тип, должны иметь возможность
использовать подтипы базового типа, не зная об этом.»
При использовании наследника класса результат выполнения кода должен быть предсказуем и не изменять свойств метода.
При использовании наследника класса результат выполнения кода должен быть предсказуем и не изменять свойств метода.
Слайд 18Liskov Substitution
Почему плохой код?
При использовании FreeOrder “ломается” OrderCollector.
FreeOrder не является настоящим
подклассом SimpleOrder.
Подкласс должен определяться на основе поведения.
Подкласс должен определяться на основе поведения.
Слайд 23Interface Segregation
Принцип разделения интерфейса
«Много специализированных интерфейсов лучше, чем один универсальный»
Соблюдение
этого принципа необходимо для того, чтобы классы-клиенты использующий/реализующий интерфейс знали только о тех методах, которые они используют, что ведёт к уменьшению количества неиспользуемого кода.
Слайд 25Interface Segregation
Почему плохой код?
Интерфейс слишком большой, что затрудняет создание классов, реализующих
его.
Большие интерфейсы не так удобно повторно использовать.
Интерфейс содержит слишком много ответственностей (вероятно нарушение SRP)
Наверняка, наследуемые классы будут создавать методы-”пустышки” для данного интерфейса (вероятно нарушение LSP)
Большие интерфейсы не так удобно повторно использовать.
Интерфейс содержит слишком много ответственностей (вероятно нарушение SRP)
Наверняка, наследуемые классы будут создавать методы-”пустышки” для данного интерфейса (вероятно нарушение LSP)
Слайд 28Dependency Inversion
Принцип инверсии зависимостей
«Зависимости внутри системы строятся на основе абстракций. Модули
верхнего уровня не зависят от модулей нижнего уровня. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций»
Зависимости должны строится относительно абстракций, а не деталей.
Зависимости должны строится относительно абстракций, а не деталей.
Слайд 30Dependency Inversion
Почему плохой код?
Зависимости от деталей приводит к снижению гибкости.
Такой код
тяжелее тестировать.
Слайд 33Заключение
SOLID — не панацея
”Любую проблему можно решить с помощью дополнительных абстракций,
кроме проблемы избыточных абстракций”
Главное — управление сложностью кода
Главное — управление сложностью кода
