Я лично представляю ООП как систему передачи сообщений. Есть разные объекты, и они обмениваются сообщениями. Передача сообщений меняет состояние объекта, состояния объекта -- это поля, которые он инкапсулирует. Сообщения передаются посредством вызова методов. objectA->run(x). Это передача сообщения run c параметром х объекту objectA, которая может привести к изменению состояния a и передаче других сообщений другим объектам. Я лично так трактую ООП. В smalltalk кстати такая парадигма на уровне языка"После каждой новой статьи с заголовком «ООП — это обман» хочется напомнить: ООП — это не набор шаблонов из книжек, а инженерный подход. Если проект страдает от наследования и DI, возможно, проблема не в ООП. А в том, как вы его применяете.
«Никто не знает, что такое ООП»
Это правда. Все трактуют по-разному. Даже сам Алан Кэй, человек, который придумал термин, не слишком рад тому, во что это всё превратилось:
> “OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.”
> — Alan Kay
Но ООП — это не набор догм. Это способ сказать: «У этой штуки есть состояние и поведение, и я хочу, чтобы они шли вместе». Не всегда нужно, но часто помогает.
«Все примеры из книжек — это кошки и собаки»
Ну конечно. Никто не станет показывать на собеседовании паттерн CQRS с Event Sourcing. Показывают Animal, потому что это просто.
Это не руководство к действию. Это иллюстрация. Как for (int i = 0; i < 10; i++) — вы же не думаете, что весь код должен быть таким?
«DTO туда-сюда, а методы всё равно чистые»
Да, и это отлично. Инкапсуляция — это не магия. Это просто «держи данные под контролем».
Не надо пихать поведение в каждый класс. Иногда класс — просто контейнер. Но если у объекта есть логика, которая зависит от его состояния — вот тогда ООП работает на вас.
«Паттерны GoF — это костыли»
Так и есть. Но это хорошие костыли. Проверенные временем.
> “The point of OOP is to manage dependencies, not to model cats and dogs.”
> — Robert C. Martin
Да, Strategy можно заменить на Func. Но стоит ли выбрасывать идею только потому, что синтаксис стал проще?
«Интерфейсы плодятся, DI магичен, всё сложно»
Сложно — когда делаете «по учебнику», не понимая зачем. Интерфейс нужен, чтобы не зависеть от реализации. DI — чтобы не было new в каждом методе.
> “SRP doesn't say you need tiny classes. It says a class should have one reason to change.”
> — Robert C. Martin
«ООП не нужен: смотри на Linux»
Конечно, в ядре Linux не до полиморфизма. Это системный код, где важны предсказуемость и скорость. Но если вы пишете код, который поддерживают 10 человек и меняют годами — с интерфейсами, классами и тестами вам будет проще.
> “All successful software gets changed. And object-oriented design helps you manage that change.”
> — Grady Booch
Вместо вывода
ООП — не серебряная пуля. Но если вы режете код, а не играете им в дартс — он может сильно помочь. Не потому что модно, а потому что позволяет думать про поведение, не теряя структуру.
Инструмент хорош, когда его используют по назначению."
...к Леви и прочему это тоже относится
Я кстати arduino взяла вчера, играюсь вечерами, когда устаю от физики. Вот там просто С, даже не С++ без всякого ООП. Но тем не менее очень много интересного кода для него есть, даже операционные системы. Для более сложных проектов с ИИ у меня Jetson Nano есть."После каждой новой статьи с заголовком «ООП — это обман» хочется напомнить: ООП — это не набор шаблонов из книжек, а инженерный подход. Если проект страдает от наследования и DI, возможно, проблема не в ООП. А в том, как вы его применяете.
«Никто не знает, что такое ООП»
Это правда. Все трактуют по-разному. Даже сам Алан Кэй, человек, который придумал термин, не слишком рад тому, во что это всё превратилось:
> “OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.”
> — Alan Kay
Но ООП — это не набор догм. Это способ сказать: «У этой штуки есть состояние и поведение, и я хочу, чтобы они шли вместе». Не всегда нужно, но часто помогает.
«Все примеры из книжек — это кошки и собаки»
Ну конечно. Никто не станет показывать на собеседовании паттерн CQRS с Event Sourcing. Показывают Animal, потому что это просто.
Это не руководство к действию. Это иллюстрация. Как for (int i = 0; i < 10; i++) — вы же не думаете, что весь код должен быть таким?
«DTO туда-сюда, а методы всё равно чистые»
Да, и это отлично. Инкапсуляция — это не магия. Это просто «держи данные под контролем».
Не надо пихать поведение в каждый класс. Иногда класс — просто контейнер. Но если у объекта есть логика, которая зависит от его состояния — вот тогда ООП работает на вас.
«Паттерны GoF — это костыли»
Так и есть. Но это хорошие костыли. Проверенные временем.
> “The point of OOP is to manage dependencies, not to model cats and dogs.”
> — Robert C. Martin
Да, Strategy можно заменить на Func. Но стоит ли выбрасывать идею только потому, что синтаксис стал проще?
«Интерфейсы плодятся, DI магичен, всё сложно»
Сложно — когда делаете «по учебнику», не понимая зачем. Интерфейс нужен, чтобы не зависеть от реализации. DI — чтобы не было new в каждом методе.
> “SRP doesn't say you need tiny classes. It says a class should have one reason to change.”
> — Robert C. Martin
«ООП не нужен: смотри на Linux»
Конечно, в ядре Linux не до полиморфизма. Это системный код, где важны предсказуемость и скорость. Но если вы пишете код, который поддерживают 10 человек и меняют годами — с интерфейсами, классами и тестами вам будет проще.
> “All successful software gets changed. And object-oriented design helps you manage that change.”
> — Grady Booch
Вместо вывода
ООП — не серебряная пуля. Но если вы режете код, а не играете им в дартс — он может сильно помочь. Не потому что модно, а потому что позволяет думать про поведение, не теряя структуру.
Инструмент хорош, когда его используют по назначению."
...к Леви и прочему это тоже относится
