[ /b/ /u/ /rf/ /dt/ /vg/ /r/ /cr/ /lor/ /mu/ /oe/ /s/ /w/ /hr/ ] [ /a/ /ma/ /sw/ /hau/ /azu/ ] [ /tv/ /cp/ /gf/ /bo/ /di/ /vn/ /ve/ /wh/ /fur/ /to/ /bg/ /wn/ /slow/ /mad/ ] [ /d/ /news/ ] [ Главная | Настройки | Закладки | Плеер ]

Ответ в тред 48832. [Назад]
 [ Скрыть форму ]
Имя
Не поднимать тред 
Тема
Сообщение
Капча Капча
Пароль
Файл
Вернуться к
  • Публикация сообщения означает согласие с условиями предоставления сервиса
  • В сообщениях можно использовать разметку wakabamark
  • На данной доске отображаются исходные имена файлов!
  • Разрешенные типы файлов: pdf, music, text, code, vector, image, archive, flash, video
  • Тред перестает подниматься после 500 сообщений.
  • Треды с числом ответов более 100 не могут быть удалены.
  • Старые треды перемещаются в архив после 40 страницы.

No.48832 Ответ
Файл: pg087.png
Png, 23.35 KB, 475×349
edit Find source with google Find source with iqdb
pg087.png
Файл: pg072.png
Png, 56.58 KB, 515×709
edit Find source with google Find source with iqdb
pg072.png
Файл: 14686072547160.png
Png, 44.08 KB, 1024×450
edit Find source with google Find source with iqdb
14686072547160.png

Как понять ООП? Я просто вот не понимаю, зачем это нужно. Безотносительно языка программирования

Вот допустим есть некие классы, классы как в плюсах. Есть методы, которые к этим классам привязаны. Зачем это вообще нужно, если можно просто сделать структуру и набор функций, которые могут с этими структурами нечто осмысленное делать?

Вот допустим есть public private protected модификаторы доступа т.е. ограничения на то, откуда какой метод можно вызывать. public можно вызывать отовсюду, private только для методов из числа public, а protected ... protected становится private при наследовании, притом наследований может быть 3 вида - тоже public, private, protected... Зачем всё это? Чем это лучше просто кучи функций, которые могут просто вызывать другие функции и работать с какими-то структурами?

Или вот методы, методы это функции, которые привязаны к конкретной структуре, но что если мне нужны методы, которые связывают два разных класса? Например это может код, переводящий из вектора в растровую картинку. Этот код должен быть методом класса для растровой или векторной картинки?
>> No.48833 Ответ
>>48832
> Как понять ООП? Я просто вот не понимаю, зачем это нужно.
Это еще один уровень абстракции. В императивном языке ты думаешь как работать непосредственно с данными, а в объектом - как работать с объектами. В этом плане ООП больше похоже на сборку лего, где у каждой детали свои характеристики, и у тебя уже не получится использовать шестеренку как кирпичик. Или как сборку ПК, где тебя уже не волнует, как и какие там чипы, транзисторы и резисторы на платах припаяны, тебе главное чтоб разъемы совпадали и по спецификациям друг к другу подходили.

> Зачем это вообще нужно, если можно просто сделать структуру и набор функций, которые могут с этими структурами нечто осмысленное делать?
Как я это понимаю - с помощью методов ты четко определяешь, что можно делать с данными в объекте (см. выше пример с лего). В случае с методами и функциями, у тебя, например, больше шансов случайно засунуть векторную структуру в функцию для растровой и в результате получить баг.

> Вот допустим есть public private protected модификаторы доступа т.е. ограничения на то, откуда какой метод можно вызывать. public можно вызывать отовсюду, private только для методов из числа public, а protected ... protected становится private при наследовании, притом наследований может быть 3 вида - тоже public, private, protected... Зачем всё это? Чем это лучше просто кучи функций, которые могут просто вызывать другие функции и работать с какими-то структурами?
Во-первых, все эти мутации public private protected друг в друга - просто особенность C++. Прими как данное. В других языках тоже свои заморочки есть. Во-вторых, эти модификаторы позволяют четко определить, какие переменные можно изменять, а какие нет. Как и в случае с методами, это еще одна защита от ошибки программиста. Ты же не всегда на 100% внимателен и трезв умом. Сегодня у тебя голова болит, завтра тебя отвлекли разговором, послезавтра тебя девушка бросила, а через неделю тебе просто лень вычитывать код на ошибки. Раз в год и палка стреляет, так что лучше сразу технически пресечь такую возможность.

> Или вот методы, методы это функции, которые привязаны к конкретной структуре, но что если мне нужны методы, которые связывают два разных класса? Например это может код, переводящий из вектора в растровую картинку. Этот код должен быть методом класса для растровой или векторной картинки?
Четкого ответа дать не могу, я бы лично написал отдельную функцию, не привязанную к какому-либо классу. На мой взгляд это зависит от архитектуры кода. Можно представить растровый класс, который постоянно жрет векторные данные, и реализовать код конвертации как метод растрового класса. А можно запариться и для каждого класса реализовать метод конвертации в противоположный формат.
>> No.48834 Ответ
>>48833
> Это еще один уровень абстракции. В императивном языке ты думаешь как работать непосредственно с данными, а в объектом - как работать с объектами. В этом плане ООП больше похоже на сборку лего, где у каждой детали свои характеристики, и у тебя уже не получится использовать шестеренку как кирпичик.
> В случае с методами и функциями, у тебя, например, больше шансов случайно засунуть векторную структуру в функцию для растровой и в результате получить баг.
Ну если взять чистый C и противопоставить его C++, то в C есть структуры (struct), и если у меня функция принимает в качестве аргумента структуру, то передать в эту функцию другую структуру просто так не выйдет, будет как минимум warning. Класс в C++ это когда насильно привязывают некоторые функции к некоторым структурам и создают некие правила, что вот есть такие функции-привязанные-к-структуре, которые можно вызывать кому угодно, а есть еще какие-то особые функции-привязанные-к-структуре, которые можно вызывать только из других функций-привязанных-к-структуре (private методы можно вызывать только из других методов класса). Каким образом это увеличивает уровень абстракции? Это просто добавляет способ задать некие ограничения. Например модификатор const для переменных, он тоже никаких абстракций не добавляет, а просто позволяет указать что переменная не может быть изменена, и чтобы компилятор еще ругался при попытке эту переменную изменить.
На абстракцию похоже разве что наследования с виртуальными методами, когда C++ компилятор создает таблицу виртуальных методов т.е. массив из указателей на функции (не нужно рукам эти массивы из указателей на функции писать). Да и есть альтернативы для vtable в других языках, например через хеш-таблицы имен методов.
В самой же идее связать структуру и некоторые функции я никакого нового уровня абстракции не вижу.
> Во-вторых, эти модификаторы позволяют четко определить, какие переменные можно изменять, а какие нет. Как и в случае с методами, это еще одна защита от ошибки программиста.
Для этого больше бы подошли какие-нибудь контракты. Например, в каком-нибудь гипотетическом ЯП сделать так, чтобы можно было объявить особый неймспейс №1, перечислив в нем некоторое множество функций. И потом объявить другой неймспейс №2, перечислив в нем другое множество функций, при этом у этого неймспейса задать особый атрибут, что функции из этого неймспейса №2 могут быть вызваны только из функций, объявленных в неймспейсе №1. Но при этом может быть и так, что функции из неймспейса №2 не могут быть вызваны из неймспейса №1. Сама идея создания подобных контрактов к ООП отношения не имеет
С плюсовыми методами класса такое кстати не работает, т.е. public методы могут вызывать private, private могут вызывать public и private, нельзя ввести запрет для private вызывать public, как и нельзя объявить какой-нибудь свой уникальный модификатор, типа public_2 и вручную выставить для него правила, что и как ему можно делать.
> Четкого ответа дать не могу, я бы лично написал отдельную функцию, не привязанную к какому-либо классу.
А еще было б неплохо, если бы такой отдельной функции можно было бы дать разрешение вызывать private методы этих двух классов и читать-писать private переменные из этих двух классов. #define private public
>> No.48835 Ответ
>>48834
Очевидно, ты не понимаешь самой идеи (инкапсуляция, полиморфизм, наследование, вот это все) и смотришь только на синтаксис.
> и если у меня функция принимает в качестве аргумента структуру, то передать в эту функцию другую структуру просто так не выйдет, будет как минимум warning.
Классический пример: у тебя есть функция copulate. В сишке ты будешь сам трахаться, плодя бесчисленные copulate(Bat), copulate(Tiger) и т.д., тогда как ООП позволяет тебе выделить общую базу и сделать единый copulate(Animal), где наследники Animal будут перенимать поведение базового класса.
> Каким образом это увеличивает уровень абстракции?
Ты не задаешь функции, функции хуйня. Ты задаешь поведение объектов класса. Ты берешь класс и говоришь, что у него есть такие-то методы, и в public методы может тыкнуться любой желающий, а в private только он сам и т.д.
> Например модификатор const для переменных, он тоже никаких абстракций не добавляет, а просто позволяет указать что переменная не может быть изменена, и чтобы компилятор еще ругался при попытке эту переменную изменить.
Замечательная вещь: позволяет отсеять часть ошибок в логике еще на этапе компиляции. Точно так же часть ошибок можно отсеять с помощью правильной установки прав доступа (public-protected-private).
> С плюсовыми методами класса такое кстати не работает, т.е. public методы могут вызывать private, private могут вызывать public и private, нельзя ввести запрет для private вызывать public, как и нельзя объявить какой-нибудь свой уникальный модификатор, типа public_2 и вручную выставить для него правила, что и как ему можно делать.
Все просто: public_2 костыль и НИНУЖНО. Имеющихся прав доступа достаточно: это не непонятно какие неймспейсы с потолка, а именно что классы и описание того, кому и что с ними можно делать. По определению public - то, что доступно любому, а потому "запрет private вызывать public" - абсурд.
Не привязывайся к функциям, а пойми саму парадигму: ты описываешь не функции, а классы. Собственно, поэтому годные программисты пишут код на уровне взаимодействия интерфейсов, а не говнокодят с реализациями.
>> No.48836 Ответ
Да говно это, учи Haskell
>> No.48837 Ответ
>>48836
Да тоже фигня, лучше учиться на перспективу - учить языки для квантового программирования.
>> No.48838 Ответ
Файл: Cylinder_Head_Sector_ru.svg.png
Png, 260.88 KB, 1200×1293 - Нажмите на картинку для увеличения
edit Find source with google Find source with iqdb
Cylinder_Head_Sector_ru.svg.png
>>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 функции.
>> No.48839 Ответ
Давайте сделаем поправку, что ООП в том виде, в котором его задумывал Алан Кей, мало где реализован. Так что да, ООП в мейнстримовых языках больше влияет на организацию кода, чем претендует на новую парадигму.
Собственно говоря, ООП в C++ не реализует ничего такого, чего нельзя было бы написать в C. Да только делается это в плюсах удобнее и безопаснее.
>> No.48840 Ответ
>>48839
> Давайте сделаем поправку, что ООП в том виде, в котором его задумывал Алан Кей, мало где реализован.
Это связано с тем, что каноничное ООП оказалось никому не нужным? Или оно было слишком сложным в реализации? Или почему?
>> No.48841 Ответ
>>48840
Без понятия. Наверное, все как всегда - теория столкнулась с практикой и изменилась.
Вот есть хорошая статья про историю идеи - https://medium.com/@atherlangga/retracing-original-object-oriented-programming-f8b689c4ce50
>> No.48847 Ответ
>>48840
Каноничное ПО никому не нужно. Тебе же пофиг, как это работает. Вот и всем тоже пофиг. А когда всем пофиг, можно "хуяк-хуяк - и в продакшон". При такой бизнес-парадигме популярными становятся языки, на которых "хуяк-хуяк" можно безопаснее и удобнее.
Если тебе действительно интересно, чем может быть полезна объектно-ориентированная парадигма, а не как её подобием обмазали наиболее популярные языки, почитай про CLOS. Если понравится, можешь ещё MOP навернуть и изучить понятие интроспекция в контексте ЯП. Если всё ещё не обретёшь понимания, что такое ООП, ну значит не готов, не нужно оно тебе.
>> No.48849 Ответ
>>48838
> Т.е. смысл ООП в том, чтоб не копипастить? И это новый уровень абстракции?
Ты опять смотришь на функции вместо того, чтобы смотреть на классы. Отсутствие тупого копипаста - лишь вытекающее из мышления на объектном уровне плюшка.
> Новый уровень абстракции это например переход ASM -> C, когда уже не нужно оперировать регистрами и инструкциями процессора. ООП это скорее некий способ организации кода (теперь функции мы привязали к структурам, пишите вот так!), а не новый уровень абстракции.
А здесь не нужно оперировать лоу-левел функциями, а нужно оперировать интерфейсами.
> А зачем ограничивать себя только таким дефолтным набором public-private-protected?
Потому что этого достаточно. Снова, не смотри на какие-то дурацкие неймспейсы как приложение к функциям. Мысли на уровне классов и интерфейсов. Есть только интерфейсы, доступные всем, недоступные никому кроме себя и недоступные никому кроме себя и потомков.
> Ну вот я приводил пример с контрактами, что одни функции могут там что-то вызывать, а другие не могут, но никакие объекты для этого не требуются, это просто выделение некоторого неймспейса функций и создание для них каких-то запретов/разрешений.
Мерзкие сишные костыли. Это называется методы работы одних объектов с другими объектами, и делается через public-protected-private, наследование и иногда friendование.
> И систему прав доступа можно сделать значительно более гибкой, чем это реализовано в ООП.
Нельзя. Есть объект, который не знает ничего об окружающем мире кроме того, что от него могут унаследоваться. Все возможные виды доступа к его интерфейсам - public, protected, private.
> Ну почему же, вполне можно представить ситуацию, когда полезно сделать ограничения вида "функции из неймспейса №1 могут вызывать только функции из неймспейса №1 и №2, функции из неймспейса №2 могут вызывать только функции из неймспейса №2 и №3, функции №3 вызывают только №3 и №4 и.т.д."
Костыли. Используй классы, Люк.
> драйвер ФС передает драйверу жесткого диска "запиши вот эти байтики вот туда-то, и вот эти байтики вот туда", при этом драйвер ФС ничего не знает про геометрию диска(дорожки, количество пластин), т.е. с точки зрения драйвера ФС, жесткий диск это просто большой массив из некоторых секторов, например секторов по 512 байт. Т.е. драйвер ФС общается с драйвером жесткого диска на уровне "запиши в тот сектор размером в 512 байт вот это" и "прочитай из того сектора размером в 512 байт и дай мне".
Быдлокод с магическими числами. ФС дергает общий интерфейс всех драйверов ЖД "Записать N-байт". Реализация этого интерфейса, представляющая конкретный HAL для конкретного диска, разбивает файл на куски в зависимости от параметров диска, формирует блок метаданных с последовательностью адресов этих блоков, записывает это все и возвращает драйверу ФС файловый дескриптор блока метаданных. Вуаля, все работает на интерфейсах ООП-стайл.
> Так вот, тут имеет смысл запретить обычной программе из юзерспейса обращаться к драйверу жесткого диска напрямую и говорить, в какие секторы что писать.
Вообще не задача программы или ЯП. Это задача ОС заделать разделение на юзерспейс и кернелспейс. В юзерспейсе доступны интерфейсы для записи и чтения файлов, опять же ООП-стайл.
> Такое можно без всякого ООП делать в чистом Си, разбив реализацию на несколько файлов и используя static функции.
Разбивать на файлы все равно придется, очевидно. А всего-то нужно - использовать нужные интерфейсы, которые можно реализовывать для любого устройства. Твою же идею ждет инстант пиздец, стоит только подключить какой-нибудь ССД ил рамдиск или дискетку вместо ЖД, лол.
>> No.48850 Ответ
>>48849
Спор слепого с глухим.
Как ООП избавляет от копипасты и при чём тут она вообще? Решения типа copulate(Bat), copulate(Tiger) можно сгенерировать независимо от парадигмы. Ни ООП, ни декларативное, ни какое-либое другое программирование не может запретить писать говнокод или копипастить.
Раньше программы писали просто перечислением команд, потом стали выделять куски кода в подпрограммы, процедуры, функции - это уже начала инкапсуляции и полиморфизма. Затем стали объединять разные встроенные типы в структуры, а функционал, работающий с такими комбинированными типами данных - всё так же в процедуры. Почему так стали делать? Потому что программы становились больше, сложнее, возникла необходимость структурировать код, чтобы его было легко анализировать, допиливать. Разные подходы к организации кода были вызваны сильно различающимися типами задач, костылей мышления погромистов и породили необходимость в расслоении на языки с разными парадигмами. Но такого чтобы парадигма лишала возможности говнокодить не было никогда. Ну разве что вот нейронные сети, практически исключив человека из, собственно, процесса формирования итоговой системы, могут как-то помочь с этим, но это уже не о парадигмах речь.
В плюсах ничего принципиально нового не вводится, никаких волшебных механизмов, исключающих говнокод. Классы - всё те же супер-типы на стероидах. Для каждой лексемы найдётся оправдание, каждая нужна для чего-то, иначе её не впилили бы. И это всё, конечно, работает, ты, конечно, можешь думать классами, наследованиями, разграничением прав для членов класса, пояснять за виртуальные функции и считать шаблоны - венцом программистской мысли. Раньше был молоток, пила, рубанок, теперь - молоток с выдвижной пилой и возможностью прикрутить сколько угодно рубанков, причём у всего этого одна ручка (удобно), и теперь ты не можешь пораниться, потому что везде наклейки "ОСТОРОЖНО!". В нормальном мире ручной инструмент уходит в прошлое, совершенствуются и материалы, и технологии строительства, и вообще автоматизация процесса даёт человеку больше свободного времени на осмысление происходящего.
>> No.48852 Ответ
>>48849
> Потому что этого достаточно. Снова, не смотри на какие-то дурацкие неймспейсы как приложение к функциям. Мысли на уровне классов и интерфейсов. Есть только интерфейсы, доступные всем, недоступные никому кроме себя и недоступные никому кроме себя и потомков.
Достаточно для чего? Если говорить о том, чего достаточно, то и обычных функций + структур вполне достаточно, а все эти public-private-protected ничего кардинально не меняют. Если же public-private-protected это что-то нужное, то почему именно на этом остановились, почему б не вводить какие-то новые права доступа?
> Мерзкие сишные костыли. Это называется методы работы одних объектов с другими объектами, и делается через public-protected-private, наследование и иногда friendование.
> Нельзя. Есть объект, который не знает ничего об окружающем мире кроме того, что от него могут унаследоваться. Все возможные виды доступа к его интерфейсам - public, protected, private.
Зачем ты говоришь догмами? Язык программирования и предоставляемые им абстракции это не какие-то незыблемые законы физики, вроде закона сохранения энергии, это просто придуманная людьми хрень, которая при желании может быть улучшена/переделана.
> > Ну почему же, вполне можно представить ситуацию, когда полезно сделать ограничения вида "функции из неймспейса №1 могут вызывать только функции из неймспейса №1 и №2, функции из неймспейса №2 могут вызывать только функции из неймспейса №2 и №3, функции №3 вызывают только №3 и №4 и.т.д."
> Костыли. Используй классы, Люк.
Я через классы не могу создавать сложный набор правил доступа, там только public, protected, private.
> Быдлокод с магическими числами. ФС дергает общий интерфейс всех драйверов ЖД "Записать N-байт".
Винчестер тебе 1 байт записать не может, там не побайтная адресация (ты б еще попросил его один бит записать, лол). Он прочитает 512 байт (или сколько у него там размер кластера) в буфер, изменит там 1 байт и потом обратно запишет 512 байт. Если ты вот так побайтно будешь писать в некий файл данные по одному байту, это будет нерационально. Лучше пусть это буферизуется, но буферизоваться это может на разных уровнях, и желательно чтобы ФС знала о том, какого размера кластер винчестера, и чтобы ФС была отформатирована соответствующим образом. Абстракция "записать N байт" протекает.
> Вуаля, все работает на интерфейсах ООП-стайл.
> В юзерспейсе доступны интерфейсы для записи и чтения файлов, опять же ООП-стайл.
ООП-стайл, ООП-стайл, ООП-стайл... идея разделения чего-либо на интерфейс и реализацию возникла ДО появления т.н. ООП. Что ты называешь ООП-стайлом?
> Твою же идею ждет инстант пиздец, стоит только подключить какой-нибудь ССД ил рамдиск или дискетку вместо ЖД, лол.
Дискеты и современная флеш-память тоже читается-пишется кусками в сколько-то байт, лол.

>>48850
> В плюсах ничего принципиально нового не вводится, никаких волшебных механизмов, исключающих говнокод. Классы - всё те же супер-типы на стероидах. Для каждой лексемы найдётся оправдание, каждая нужна для чего-то, иначе её не впилили бы. И это всё, конечно, работает, ты, конечно, можешь думать классами, наследованиями, разграничением прав для членов класса, пояснять за виртуальные функции и считать шаблоны - венцом программистской мысли. Раньше был молоток, пила, рубанок, теперь - молоток с выдвижной пилой и возможностью прикрутить сколько угодно рубанков, причём у всего этого одна ручка (удобно), и теперь ты не можешь пораниться, потому что везде наклейки "ОСТОРОЖНО!".
Ну так вот я и говорю, плюсовые классы это такие недоконтракты, типа "public можно вызывать, а вот private можно только из public". Когда я говорю "а зачем только public-private-protected, почему б не сделать более общий механизм", мне он отвечает "так неположено, неканонично, костыли".
Наследование это просто такой инструмент для борьбы с копипастой, недокодогенерации (намного лучше с этим делом обстоит в лиспе, где код = данные).
Зачем использовать более узкие (вероятно, намеренно суженные) механизмы, и почему более общие методы это что-то плохое.
>> No.48853 Ответ
>>48852
> Достаточно для чего?
Для реализации ООП-подхода. В пределе все есть объект какого-то класса.
> Зачем ты говоришь догмами? Язык программирования и предоставляемые им абстракции это не какие-то незыблемые законы физики, вроде закона сохранения энергии, это просто придуманная людьми хрень, которая при желании может быть улучшена/переделана.
Придумай другой тип доступа, кроме public, protected и private. Не неймспейсики, а именно тип доступа к классу, про который известно только то, что есть еще и другие классы, и что от него можно наследоваться.
> Я через классы не могу создавать сложный набор правил доступа, там только public, protected, private.
Значит, ты не умеешь программировать в ООП. Гугли, как делать интерфейсы.
> Винчестер тебе 1 байт записать не может, там не побайтная адресация (ты б еще попросил его один бит записать, лол). Он прочитает 512 байт (или сколько у него там размер кластера) в буфер, изменит там 1 байт и потом обратно запишет 512 байт. Если ты вот так побайтно будешь писать в некий файл данные по одному байту, это будет нерационально. Лучше пусть это буферизуется, но буферизоваться это может на разных уровнях, и желательно чтобы ФС знала о том, какого размера кластер винчестера, и чтобы ФС была отформатирована соответствующим образом. Абстракция "записать N байт" протекает.
Наоборот, именно абстракция и решает.
Мне плевать, как там внутри все устроено, какой размер кластера и т.д. Я хочу создать файл в 1 байт и сохранить его на диск. Ты будешь лихорадочно искать подходящую функцию, вручную создавать буфер и наполнять его нулями? Это жопорукость. Ты вызовешь метод и передашь файл в 1 байт, а как там внутри реализовано, что он там прочитает и запишет, не важно. Ты дернешь интерфейс записи N байт, а проверки на N < размера кластера должны быть скрыты внутри и как-то там магически решаться, вплоть до буферизаций и дрочки вприсядку.
> идея разделения чего-либо на интерфейс и реализацию возникла ДО появления т.н. ООП.
Интересно, как ты ее реализуешь на голом С. Без указателей на void.
> Дискеты и современная флеш-память тоже читается-пишется кусками в сколько-то байт, лол.
Все пишется кусками минимум в 1 байт, лол.
>> No.48863 Ответ
>>48832

> > есть некие классы
> > Есть методы, которые к этим классам привязаны
> > Зачем это вообще нужно, если можно просто сделать структуру и набор функций
Все верно говоришь, тебе оно и не нужно в домашних условиях. Используй то, что нужно.
Рано или поздно у тебя возникнет потребность в классах.

> > вот допустим есть public private protected модификаторы доступа
> > наследований может быть 3 вида - тоже public, private, protected...
> > Зачем всё это?
Тебе не за чем. А если бы ты кодил хотя бы вдвоем, то быстро бы понял, что некоторые вещи другой человек видеть, наследовать и тд не должен.

> > Этот код должен быть методом класса для растровой или векторной картинки?
Не, это должно быть что-то третье.


Пароль:

[ /b/ /u/ /rf/ /dt/ /vg/ /r/ /cr/ /lor/ /mu/ /oe/ /s/ /w/ /hr/ ] [ /a/ /ma/ /sw/ /hau/ /azu/ ] [ /tv/ /cp/ /gf/ /bo/ /di/ /vn/ /ve/ /wh/ /fur/ /to/ /bg/ /wn/ /slow/ /mad/ ] [ /d/ /news/ ] [ Главная | Настройки | Закладки | Плеер ]