ООП — это скам

иии снова путаем объектно-ориентированное программирование и синтаксис произвольного языка "с классами".

Без иронии или негатива спрашиваю. Что тогда такое ООП?

ООП — это скам

Забыл ссылку прикрепить - https://go.dev/doc/faq#Is_Go_an_object-oriented_language

ООП — это скам

Вот программирование на таких структурах данных и стали называть объектно-ориентированным.

Против такого подхода я не имею ничего против. Но я сомневаюсь, что все понимают под ООП именно это

ООП — это скам

Будет

Где будет? Будет репозиторий с методами Save/Read, который этого юзера принимает в качестве аргумента. Ну по крайней мере в 99% проектах на ООП-языках (и не только на них).

Что интересно, у Егора Бугаенко был доклад на тему, где он как раз топил за отказ от репозиториев и продвигал идею класса User, который сам себя может сохранить в базу.

Реакция зала и комментарии на ютубе были ожидаемые. Мало кто поддержал такой подход

ООП — это скам

Вопрос холиварный, но нам точно нужны фреймворки? Я видел масштабные (по моим меркам) монолиты и на C#, и на go. Отсутствие или наличие фреймворков в таких проектах - это меньшая из проблем

ООП — это скам

Я про это и пишу. В учебниках по ФП описываются инструменты, которыми потом пользуются в реальном коде. В учебниках по ООП приводят в пример собак и кошек, которые умеют говорить и наследуются от класса Animal. Но в реальном коде оказывается, что "На границах ООП не является ООП", откуда-то берутся сервисы и контроллеры, которые просто гоняют данные и пр

ООП — это скам

инкапсуляция – это private, protected

Я же привёл несколько определений инкапсуляции. И они все разные. И это одна из моих претензий

ООП — это скам

1. Я начал зарабатывать программированием на третьем курсе университета, работая на половину ставки. Если считать этот опыт, то 7 лет

2. Потому что SOLID придумали в первую очередь для ООП. Как и те самые паттерны от банды четырёх.

3. Я не пишу про достоинства функционального программирования. Я пишу про недостатки ООП и не предлагаю людям массово уходить в Haskell или F#.

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

ООП — это скам

Цитата из моей же статьи

Удобнее и проще говорить про характерные признаки ООП. И они есть, что не может не радовать. Их озвучил программист и учёный Алан Кэй, который официально и считается автором термина "Объектно-ориентированное программирование". В последствии его идеи были реализованы в языке Simula. Алану реализация не совсем пришлась по вкусу, поэтому он пошёл делать свой язык - так и появился Smalltalk.

ООП — это скам

Поправил, спасибо

ООП — это скам

Так на кой черт вы всю статью перед этим пытаетесь абсолютно все проблемы решать только этими инструментами?

Потому что раньше по-другому не умели. Поэтому инкапсуляция, наследование и полиморфизм считались базой и чуть ли не серебряной пулей. Но по факту оказалось, что те же проблемы куда удобнее решать другими способами. И по мере развития языков надобность в трёх столпах ООП уменьшалась. При этом в гайдах по-прежнему объясняют ООП через собак и животных с методом Say, а некоторые фреймворки проектируются с оглядкой на Spring.

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

В дальнейшем мы как раз в большинстве начинаем писать обычный сишный код, но завёрнут он не в функции и типы, а в классы и методы, что лично у меня вызывает массу недоумений

Я вам сейчас наверное весь шаблон сломаю:

Признаюсь, сломали. Не могу не спросить, что такое тогда ООП? Я вижу набор функций, которые принимают аналог джавовского "интерфейса" в качестве первого аргумента. typedef был в C с самого начала. Выходит, C - это язык с полноценной поддержкой ООП?

ООП — это скам

Или для вас ООП язык - этот тот где нельзя просто процедуры без класса писать?

Я как раз и говорю, что о понятие ООП размыто до невозможности. Выше мне пишут, что ООП - это только про инкапсуляцию. В таком случае она есть в любом языке.

И да - в Go - все есть interface{} - пихай куда угодно, что угодно

С появлением дженериков возможность абьюзить interface{} практически исчезла

ООП — это скам

Java и C# - языки своего времени, где отменили "просто функции", да, это сомнительно по итогу оказалось

Тут соглашусь. Сильный перекос в ФП тоже не одобряю, хотя не могу сказать, что где-то массово его наблюдаю в новых языках. В каких языках это заметно? Разве что ts со своей безумной системой типов, где есть вообще всё

ООП — это скам

Странно. Я открываю официальный FAQ по go. И там есть вопрос "Is Go an object-oriented language?", на который авторы отвечают: "Yes and no".

Вы же утверждаете, что ООП - это только инкапусляция. То есть go вроде как является полноценным ООП-языком, хотя авторы зяыка не дают однозначного положительного ответа.

Это я всё к тому, что общепринятого определения ООП у сообщества нет. Каждый понимает его по-своему. Из-за этого и правила для написания правильного кода в стиле ООП у всех отличаются

ООП — это скам

Я пишу на go. Классического ООП там нет. Есть типы, к которым можно присобачить методы. Типа такого:

type User struct {
  Name string
}

func (u User) Say() {
  fmt.Println(u.Name)
}

ООП — это скам

Я открыл сорцы компилятора go. И он написан на go.

Какую серебряную пулю я продаю в статье? Нет ни слова про ФП или императивное программирование. И никакой конкретный язык я не рекламирую.

А вот условная java как раз пытается это сделать. Потому что всё есть объект, метод может находиться только внутри класса, обычных типов нет, функций нет, пиши геттер и сеттер на каждое поле своего класса (даже если тебе это не нужно, а такое бывает часто). Это куда больше похоже на серебряную пулю

ООП — это скам

Хейтерам предлагаю показать миру хоть немного крупный backend или gamedev проект без ООП, пусть все оценят

А почему только бэкенд или геймдев? Вот есть у нас docker, tarantool, prometheus, lazygit, cockroach. Они все написаны на go. На нём же было написан бэк для дискорда, пока авторы не переехали на rust из-за ограничений GC.

Для чистого С уже сложнее, навскидку вспомнил vim, neovim, redis. Хотя там мешанина языков, а в neovim даже C++ есть.

Чем не крупный список проектов, которые написаны на языках, у которых нет встроенной поддержки ООП?

ООП — это скам

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

То есть взял я джаву, например. И она мне упорно говорит, что мой объект User без методов и даже логики в сеттерах - это полноценный класс. Просто объявить функцию я не могу, потому что нет никаких функций, есть некие статические классы со статическими методами. Появляется какая-то проблема, которую можно решить несколькими способами, а приходится решать её через полиморфизм, потому что у нас тут ООП, так что написать просто пару ифов нельзя, ибо это автоматически приравнивается к говнокоду.

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

ООП — это скам

Отвечу по порядку.

На данный момент пишу CRM и систему документооборота. Разрабатывал систему для деплоя, сайт для подбора банковских продуктов.

Из вашего комментария не особо понятно, где в вашей задаче нужно ООП. Я ничего не знаю про хлор и строительство жилых домов. Из пары абзацов сложно внятно понять доменную модель и составить ТЗ. Тут минимум день надо погружаться в тему, чтобы хоть как-то в голове код накидать

ООП — это скам

Так а к чему цепляться как не к реализациям? На бумаге многие идеи звучат хорошо или нейтрально, но на практике получается не очень.

Если бы мне кто-то до появления ООП предложил идею языка, где всё есть объект и где данные привязаны к поведению, то я не стал бы возражать. Но оценить идею полноценно смог бы только после реализации