>>5014404> "сахар для программиста" над обычным потоком кода и для компьютера что она есть, что её нету без разницы
Добро пожаловать в мир, где код не только пишут, но и читают и поддерживают. Время работы программиста почти везде стоит дороже, чем время работы компа. Как думаешь, какой проект будет успешнее - тот, который работает на 10% быстрее, или тот, который выкатывает новые фичи и фиксит баги на 10% быстрее?
> И каких же? Просто интересно.
Ты учти, что вещи, которые тебе кажутся банальными, когда-то были прорывными. Почитай про structured programming, например.
Работу алгоритма можно представить как процесс взаимодействия нескольких сущностей ("объектов"), причем у них есть "внешний вид" и "внутренний вид", второй - более детализован чем первый, но недоступен "снаружи". Таким образом, можно одним взглядом в общих чертах понять, что происходит, а при необходимости - углубиться в детали работы конкретной сущности, чтобы получить более точное представление.
Бонусом такого подхода является то, что две сущности с одинаковыми "внешними видами" взаимозаменяемы в том смысле, что вместо одной можно подсунуть другую без серьезных изменений в том, как окружающие работают с этой сущностью, в идеале - вообще без изменений, и это все при том, что "внутри" эта сущность может быть совсем иной. На самом деле даже круче - если у нас используется какое-то подмножество "внешнего вида" сущности, то вместо нее можно подсунуть другую сущность, чей "внешний вид" содержит то же подмножество. Это все позволяет один раз написать код, который будет работать со всем многообразием сущностей, чей "внешний вид" содержит необходимые элементы. DRY во все поля.
Также оказывается, что не обязательно составлять сущности с нуля - можно придумать способы как из одной сущности сделать много сущностей, содержащих тот же внешний вид, возможно. с некоторыми доработками и уточнениями.
В принципе, это довольно банальные вещи, которые позволяют разбить сложный процесс на более мелкие, удобоваримые, части и предоставить способ навигации по коду, позволяющий получать достаточную, но не избыточную, детализацию.
Замечу, что ни классы, ни методы не являются тут обязательными, но они довольно удобны и широко понятны, потому широко используются. Тем более, не надо равнять ООП в целом и ООП как оно представлено в плюсах или джаве - это весьма специфические имплементации, содержащие предположения о предметной области, которые у тебя могут не выполняться, да и просто исторический мусор.
