Спустя 2 года разработки я наконец сформировал для себя более менее ясную, и, что немаловажно, простую картину о том, что есть ООП и как объяснить все его 4 принципа на простейшем примере за 5 минут.
Для понимания достаточно базового знания любого C-подобного языка
Возьмем простейший пример на PHP: Вот и всё. Если проанализировать все популярные паттерны проектирования, они будут, по сути, разными комбинациями того, как можно эти принципы использовать на практике. Если кто-то не согласен со мной, буду рад поспорить! Спасибо за внимание!
Спустя 2 года разработки я наконец сформировал для себя более менее ясную, и, что немаловажно, простую картину о том, что есть ООП и как объяснить все его 4 принципа на простейшем примере за 5 минут.
Для понимания достаточно базового знания любого C-подобного языка
Возьмем простейший пример на PHP:
- Полиморфизм: Shape в данном случае - это интерфейс, мы не знаем, какой именно объект получит функция do: квадрат, треугольник и т.п. Таким образом, одно и то же может сделать любой объект, который явно имплементирует данный интерфейс, реализовав логику метода square. Налицо полиморфное поведение.
- Абстракция: функция do взаимодействует с интерфейсом, т.е. с абстракцией. Она не знает, какой именно объект она получит.
- Инкапсуляция: все данные и логика по расчету площади фигуры скрыты от функции do. Тут кто-то возразит, что инкапсуляция - это защита данных. Еще кто-то скажет, что инкапсуляция - это локализация данных и логики по работе с этими данными в одном месте. Точка зрения про защиту данных, как по мне, вообще не в кассу, а вот с локализацией всё интереснее. Действительно, во многих умных книжках и статьях пишут, что данные и логику по работе с ними нужно хранить в одном месте. Мне нравится такой подход и я им пользуюсь. Но всё-таки в контексте взаимодействия объектов в системе я склонен делать акцент не на том, где всё хранится, а нам том, чтобы клиент знал как можно меньше об используемом объекте. А уже благодаря тому, что всё, что нужно объекту, в нем уже есть, это и реализуется.
- Наследование: благодаря наследованию, к примеру, нового класса Circle от интерфейса Shape станет возможна вся эта "магия". Да, наследование позволяет повторно использовать код, но такое его применение часто порождает огромные, забагованные и сложные для поддержки иерархии классов. Для повторного использования кода идеально подходит, к примеру, композиция, которая в сочетании с паттерном "Dependency Injection" позволяет писать классный код. На самом деле киллер фича наследования в том, чтобы быть средством для реализации всех остальных принципов ООП.
Вот и всё. Если проанализировать все популярные паттерны проектирования, они будут, по сути, разными комбинациями того, как можно эти принципы использовать на практике. Если кто-то не согласен со мной, буду рад поспорить! Спасибо за внимание!