Физкультура - это любая физическая активность. Если вы занимаетесь с железом и на тренажёрах для здоровья и хорошего самочувствия, то это всё ещё физкультура.
Если же вы начинаете считать КБЖУ, чтобы похудеть или набрать массу, то это уже бодибилдинг
Вы сейчас называете опыт программистов накопленный десятилетиями просто каким-то развлечением? Или вы не знаете как примеры из книжки применять на реальные проекты?
Ну справедливости ради вот эта идея бесшовной замены постгреса на монгу выглядит утопичной. На простом круде это сработает, но на более сложном примере начнутся нюансы.
Это разные базы данных про разные вещи. Например, простой select for update для нескольких записей просто так не сделаешь. Каскадного удаления тоже нет. И это первое, что пришло в голову.
А вот примеры из книжек как раз слишком удобные, там всегда всё слишком легко получается
Просто ООП надо начинать изучать не с изучения каких-то языков, в которых накручено множество инструментов для реализации тех или иных концепций ООП, а с базовых понятий, которых не так уж и много
Но не существует никакой базы по ООП. Я загуглил "основные понятия ООП" и кликнул по первым трём сайтам. И что я нашёл:
Где будет? Будет репозиторий с методами Save/Read, который этого юзера принимает в качестве аргумента. Ну по крайней мере в 99% проектах на ООП-языках (и не только на них).
Что интересно, у Егора Бугаенко был доклад на тему, где он как раз топил за отказ от репозиториев и продвигал идею класса User, который сам себя может сохранить в базу.
Реакция зала и комментарии на ютубе были ожидаемые. Мало кто поддержал такой подход
Вопрос холиварный, но нам точно нужны фреймворки? Я видел масштабные (по моим меркам) монолиты и на C#, и на go. Отсутствие или наличие фреймворков в таких проектах - это меньшая из проблем
Я про это и пишу. В учебниках по ФП описываются инструменты, которыми потом пользуются в реальном коде. В учебниках по ООП приводят в пример собак и кошек, которые умеют говорить и наследуются от класса Animal. Но в реальном коде оказывается, что "На границах ООП не является ООП", откуда-то берутся сервисы и контроллеры, которые просто гоняют данные и пр
Я начал зарабатывать программированием на третьем курсе университета, работая на половину ставки. Если считать этот опыт, то 7 лет
Потому что SOLID придумали в первую очередь для ООП. Как и те самые паттерны от банды четырёх.
Я не пишу про достоинства функционального программирования. Я пишу про недостатки ООП и не предлагаю людям массово уходить в Haskell или F#.
Проблема не в том, что я не могу сделать что-то без наследования. Проблема в том, что по мере развития языков необходимость в инструментах ООП отпадала, но саму концепцию ООП продолжают продвигать как серебряную пулю
Удобнее и проще говорить про характерные признаки ООП. И они есть, что не может не радовать. Их озвучил программист и учёный Алан Кэй, который официально и считается автором термина "Объектно-ориентированное программирование". В последствии его идеи были реализованы в языке Simula. Алану реализация не совсем пришлась по вкусу, поэтому он пошёл делать свой язык - так и появился Smalltalk.
Так на кой черт вы всю статью перед этим пытаетесь абсолютно все проблемы решать только этими инструментами?
Потому что раньше по-другому не умели. Поэтому инкапсуляция, наследование и полиморфизм считались базой и чуть ли не серебряной пулей. Но по факту оказалось, что те же проблемы куда удобнее решать другими способами. И по мере развития языков надобность в трёх столпах ООП уменьшалась. При этом в гайдах по-прежнему объясняют ООП через собак и животных с методом Say, а некоторые фреймворки проектируются с оглядкой на Spring.
Потому что это просто иллюстративный пример. В дальнейшем мы пользуемся ООП как инструментом для описания объектов, с которыми работает программа.
В дальнейшем мы как раз в большинстве начинаем писать обычный сишный код, но завёрнут он не в функции и типы, а в классы и методы, что лично у меня вызывает массу недоумений
Я вам сейчас наверное весь шаблон сломаю:
Признаюсь, сломали. Не могу не спросить, что такое тогда ООП? Я вижу набор функций, которые принимают аналог джавовского "интерфейса" в качестве первого аргумента. typedef был в C с самого начала. Выходит, C - это язык с полноценной поддержкой ООП?
Теперь даже комменты ИИ пишут...
Физкультура - это любая физическая активность. Если вы занимаетесь с железом и на тренажёрах для здоровья и хорошего самочувствия, то это всё ещё физкультура.
Если же вы начинаете считать КБЖУ, чтобы похудеть или набрать массу, то это уже бодибилдинг
Последний обсуждаемый issue был как раз про ? - https://github.com/golang/go/issues/71203
После долгих и бурных обсуждений issue ожидаемо закрыли с пометкой «not planned»
Ну справедливости ради вот эта идея бесшовной замены постгреса на монгу выглядит утопичной. На простом круде это сработает, но на более сложном примере начнутся нюансы.
Это разные базы данных про разные вещи. Например, простой select for update для нескольких записей просто так не сделаешь. Каскадного удаления тоже нет. И это первое, что пришло в голову.
А вот примеры из книжек как раз слишком удобные, там всегда всё слишком легко получается
Почему именно докера?
Какие гарантии и плюшки даёт монолит на C#? И почему условный PHP их не даёт?
Понятно, почему к вам никто работать не идёт
Лекции писать, например
Но не существует никакой базы по ООП. Я загуглил "основные понятия ООП" и кликнул по первым трём сайтам. И что я нашёл:
https://zinvapel.github.io/it/prog/oop/2017/10/30/oop-base/ - очень много правил. Условный закон Деметры, который тоже есть в списке, считается столпом ООП?
https://practicum.yandex.ru/blog/obektno-orientirovannoe-programmirovanie/#principy-oop - здесь просто инкапсуляция, наследование и полиморфизм
https://blog.skillfactory.ru/glossary/oop-obektno-orientirovannoe-programmirovanie/ - здесь инкапсуляция, наследование, полиморфизм и абстрагирование
Ещё и определение инкапсуляции на этих сайтах отличается.
Вы можете ответить, что надо читать первоисточник. Но автор термина ООП не считает, что в C++ есть то самое ООП. Так где читать ту самую базу по ООП?
Без иронии или негатива спрашиваю. Что тогда такое ООП?
Забыл ссылку прикрепить - https://go.dev/doc/faq#Is_Go_an_object-oriented_language
Против такого подхода я не имею ничего против. Но я сомневаюсь, что все понимают под ООП именно это
Где будет? Будет репозиторий с методами Save/Read, который этого юзера принимает в качестве аргумента. Ну по крайней мере в 99% проектах на ООП-языках (и не только на них).
Что интересно, у Егора Бугаенко был доклад на тему, где он как раз топил за отказ от репозиториев и продвигал идею класса User, который сам себя может сохранить в базу.
Реакция зала и комментарии на ютубе были ожидаемые. Мало кто поддержал такой подход
Вопрос холиварный, но нам точно нужны фреймворки? Я видел масштабные (по моим меркам) монолиты и на C#, и на go. Отсутствие или наличие фреймворков в таких проектах - это меньшая из проблем
Я про это и пишу. В учебниках по ФП описываются инструменты, которыми потом пользуются в реальном коде. В учебниках по ООП приводят в пример собак и кошек, которые умеют говорить и наследуются от класса Animal. Но в реальном коде оказывается, что "На границах ООП не является ООП", откуда-то берутся сервисы и контроллеры, которые просто гоняют данные и пр
Я же привёл несколько определений инкапсуляции. И они все разные. И это одна из моих претензий
Я начал зарабатывать программированием на третьем курсе университета, работая на половину ставки. Если считать этот опыт, то 7 лет
Потому что SOLID придумали в первую очередь для ООП. Как и те самые паттерны от банды четырёх.
Я не пишу про достоинства функционального программирования. Я пишу про недостатки ООП и не предлагаю людям массово уходить в Haskell или F#.
Проблема не в том, что я не могу сделать что-то без наследования. Проблема в том, что по мере развития языков необходимость в инструментах ООП отпадала, но саму концепцию ООП продолжают продвигать как серебряную пулю
Цитата из моей же статьи
Поправил, спасибо
Потому что раньше по-другому не умели. Поэтому инкапсуляция, наследование и полиморфизм считались базой и чуть ли не серебряной пулей. Но по факту оказалось, что те же проблемы куда удобнее решать другими способами. И по мере развития языков надобность в трёх столпах ООП уменьшалась. При этом в гайдах по-прежнему объясняют ООП через собак и животных с методом Say, а некоторые фреймворки проектируются с оглядкой на Spring.
В дальнейшем мы как раз в большинстве начинаем писать обычный сишный код, но завёрнут он не в функции и типы, а в классы и методы, что лично у меня вызывает массу недоумений
Признаюсь, сломали. Не могу не спросить, что такое тогда ООП? Я вижу набор функций, которые принимают аналог джавовского "интерфейса" в качестве первого аргумента. typedef был в C с самого начала. Выходит, C - это язык с полноценной поддержкой ООП?