>>48835> Классический пример: у тебя есть функция copulate. В сишке ты будешь сам трахаться, плодя бесчисленные copulate(Bat), copulate(Tiger) и т.д., тогда как ООП позволяет тебе выделить общую базу и сделать единый copulate(Animal), где наследники Animal будут перенимать поведение базового класса.
Т.е. смысл ООП в том, чтоб не копипастить? И это новый уровень абстракции?
Новый уровень абстракции это например переход ASM -> C, когда уже не нужно оперировать регистрами и инструкциями процессора. ООП это скорее некий способ организации кода (теперь функции мы привязали к структурам, пишите вот так!), а не новый уровень абстракции.
> Ты не задаешь функции, функции хуйня. Ты задаешь поведение объектов класса. Ты берешь класс и говоришь, что у него есть такие-то методы, и в public методы может тыкнуться любой желающий, а в private только он сам и т.д.
А зачем ограничивать себя только таким дефолтным набором public-private-protected? Может ООП является частным случаем более общей парадигмы, т.е. идеи выставлять на что-то какие-то разрешения? Ну вот я приводил пример с контрактами, что одни функции могут там что-то вызывать, а другие не могут, но никакие объекты для этого не требуются, это просто выделение некоторого неймспейса функций и создание для них каких-то запретов/разрешений. Такие же запреты/разрешения можно определять относительно каких-нибудь структур, и это можно сделать намного более гибко, типа вот только функции из этого неймспейса могут работать вот с этими структурами, а вот функции из этого неймспейса могут работать с другими структурами, а еще какие-то функции могут и с теми и с теми структурами работать.
> Замечательная вещь: позволяет отсеять часть ошибок в логике еще на этапе компиляции. Точно так же часть ошибок можно отсеять с помощью правильной установки прав доступа (public-protected-private).
Я и не спорю, но на новую парадигму это не тянет. Это просто возможность ставить самому себе какие-то ограничения. И систему прав доступа можно сделать значительно более гибкой, чем это реализовано в ООП.
> Все просто: public_2 костыль и НИНУЖНО. Имеющихся прав доступа достаточно: это не непонятно какие неймспейсы с потолка, а именно что классы и описание того, кому и что с ними можно делать. По определению public - то, что доступно любому, а потому "запрет private вызывать public" - абсурд.
Ну почему же, вполне можно представить ситуацию, когда полезно сделать ограничения вида "функции из неймспейса №1 могут вызывать только функции из неймспейса №1 и №2, функции из неймспейса №2 могут вызывать только функции из неймспейса №2 и №3, функции №3 вызывают только №3 и №4 и.т.д."
Например представим, что у нас есть гипотетический компьютер с жестким диском с магнитными блинами, и жесткий диск своего контроллера не имеет (управление осуществляется центральным процессором). Есть ОС на этом компьютере, и нам надо создать файл и записать в него такие-то данные. Вот тут можно вводить некие слои с разделением прав. Когда некая программа из юзерспейса просит ОС создать такой-то файл и записать в него такие-то байтики, ядро передает драйверу файловой системы указание "создай такой-то файл и запиши в него то-то", драйвер ФС передает драйверу жесткого диска "запиши вот эти байтики вот туда-то, и вот эти байтики вот туда", при этом драйвер ФС ничего не знает про геометрию диска(дорожки, количество пластин), т.е. с точки зрения драйвера ФС, жесткий диск это просто большой массив из некоторых секторов, например секторов по 512 байт. Т.е. драйвер ФС общается с драйвером жесткого диска на уровне "запиши в тот сектор размером в 512 байт вот это" и "прочитай из того сектора размером в 512 байт и дай мне". В драйвере жесткого диска обращение на чтение/запись такого-то сектора транслируется по каким-то формулам, учитывающим скорость вращения блинов, угол поворота коромысла с магнитными головками, и напрямую управляет всем этим. Так вот, тут имеет смысл запретить обычной программе из юзерспейса обращаться к драйверу жесткого диска напрямую и говорить, в какие секторы что писать. Обычная программа не должна управлять поворотом коромысла с магнитными головками, менять скорость вращения двигателя и прочего (то, что делает драйвер ЖД). Драйвер файловой системы тоже не должен управлять напрямую поворотом коромысла, а только лишь просить у драйвера ЖД, чтобы он туда-то записал/прочитал. А сам драйвер жесткого диска совершенно точно не должен обращаться к каким-нибудь вышележащим функциям, например драйверу ЖД незачем обращаться к драйверу ФС типа "драйвер ФС, давай удали вот этот файл". Т.е. из более низкого уровня нет смысла вызывать более высокий уровень. В ООП private имеет право вызывать и private и public, там нельзя строить такие правила.
Такое можно без всякого ООП делать в чистом Си, разбив реализацию на несколько файлов и используя static функции.