Когда ООП поможет вам?

Первое доходчивое объяснение. Спасибо

Привет Володя. А я Андрей и я алкоголик....

Спасибо за видос. Вот ищу информацию, но всё равно не понимаю зачем нужно ооп. Кажется, что и до него уже всё было.

Это Господь, Господь
И Иисус Христос, Господь
И это Господь, Господь
И Иисус Христос, Господь
И это Господь, Господь
И Иисус Христос, Господь
И это Господь, Господь
И Иисус Христос, Господь

я даже не вижу разницы между классом и функцией :(. Кто может подсказать на реальном примере в чем преимущество ооп?

Ядро linux миллионы строк кода, СИ, динамично, как-то обошлись без ООП

Господи исусе!

Лайк тебе, говорящая борода. Хоть бы обмолвился, какие языки ооп, а какие нет.

Вообщем такая проблема, смотрю ваши ролики и не могу остановиться, что делать то?

Володя, добрый день. Спасибо за ваши видео - очень доходчиво объясняете.Скажите, планируется ли видео о полиморфизме? Этот вопрос, на сколько я понимаю, актуален и по сей день.

тут немного на молодого столлмана похож ))

Мне кажется или в конце видео , за кадром, чайник закипел ?))

А где полиморфизм?

ООП обратно пропорционально продуктивно пониманию алгоритма в целом ))) все всегда стремиться к одному универсальному объекту а ООП с 1 Объектом это уже не ООП ))))

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

ООП себя очень хорошо чувствует в сущностях, когда нужно множество объектов с одного класса (например класс работы с файлом, или окно на рабочем столе, или фигура). В процедурном стиле это будет выглядеть как функция с +1 аргументом (неким дескриптором типа this) :)
Но все это не важно, сейчас стало очень распространена анемичная модель, когда данные "тонкие" и их передаю сервисам для обработки, которые не имеют внутренних состояний - ничего не напоминает? То есть это и есть процедурный стиль, люди опять пришли к тому что интуитивно правильно, но только через монструозный ООП, с тучей слоев (где наверно половина кода ничего не делает, а обслуживает работу сотни классов между собой). Такая же ситуация с дроблением классов на мелкие части, чуть ли не до пару методов.

И это все весело :)

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