Никем не понятая концепция.
Пиздато в теории, на практике хуярь лишь бы работало, потом если ч0 костыль подставим
Начни лучше с понедельника.
>Объектно Ориентированное Грограммирование
>
>Что можешь сказать про него, анон?
Наследование противоречит инкапсуляции, ООП мертво by design.
Например? Ты же сам выбираешь, что наследуется, а что нет.
Хочу сказать что это для рабов.
>инкапсуляции
Выдумали еще в Си-говне
Доделали еще в Делфи с процедурами
Само же ООП-говно протиречит в том что данные вместе с кодом. В реальности например берем любую форму учета, мы бланк формируем заполняем в него операцию, после преобразуем данные с него в базу(журнал-ордера, главную книгу) и работает с данными. А не запрашиваем каждый раз первичный документ.
Ну и сама калопсуляция по сути хуйня в реальности тоже не существует в итоге чтобы бочка наследуемая от бокс не двигалась ей добавляют 60тонн весса, вместо создать текстурку с колизей и мэшами.
>наследуется
Ток данные надо наследовать а не стрктуру, а не после тягать по 5 гигов кода для передвижения кошки с 40 ногами(сороконожки)
>Ты же сам выбираешь, что наследуется, а что нет.
Ебать, спасибо, нахуй, что разрешил.
А если я решу что ничего не должно наследоваться - это останется ООП?
И если никакого принудительного наследования нет - зачем возводить его в лозунг?
>ООП мертво by design.
Мертво благодаря математике скорее.
Если ты можешь предсказать результат 2+2 то сразу пишешь 4, а не можешь то сосешь хуй с костылями.
Типо посылаешь в черную коробку(ПВЗ) запрос а нету ли там твоих трусов, а тебе не извесно обработали ли запрос, нашли ли трусы твои или отдали твоему соседу случайно. Но тут уже затык в том, а откуда мы знаем что ящик(ПВЗ) может чет сделать?
Сороконожки ИРЛ не наследуются от кошек. Зачем ты их наследуешь в коде?
Наследует от ДНК(перфоленты)
Как ты сделаешь принудительным наследование, если только ты знаешь семантику своих классов? И это не лозунг, а определение. Если ты отказешься от наследования, ты будешь писать не в ООП-парадигме.
Какая еще перфолента? Шизик что ли?
Сложно, интересно. Люблю бессмысленные абстракции над абстракциями.
Все парадигмы хороши в меру, не стоит ударяться в крайности.
И вообще ООП-дрысня с времен визуального похрюмирования где условная телефонистка провода между слотами втыкала чтобы соединить и чет посчитать. Мол, ого это надо учиться в 10 лет чтобы кодить на Си-говне, можно же всю задачу разбить на 200 подзадач и дать индусам кодить свое говно с petyh->>kukareku(f abc)
НАСТОЯЩИЙ ПРОГРАММИСТ конечно же может двадцать мегабайт идеально оптимизированного лапшекода в голове держать. Ему никакие абстракции не нужны, они только производительность снижают.
SVO
Я еду на машине
OVS
Машина везет меня
Так-что ты серешь, потому-что в реальности нет никаких объектов если материю не считать за мэш-хуйню. И существует еще пространство.
По этому ты можешь кодить что каждый объект с лайфтайм 0 идет в мусорку. А можешь чтобы каждый объект сам себя в мусорку кидал в случаю чего.
Но тут уже затык в проце, он императивен и ваще многопоток не особо любит, и лезть каждый объект чтобы посмотреть чо ему самому делать поеботой попахивает.
Пишут функции, а потом их обобщают выносят за скобки, ты же предлагаешь делать все наоборот, предсказать что будет делать программа лет так через 4
>абстракции
Аьстракции до предпроцессора даже не доживают. Ты путаешь все.
>SVO
>Я еду на машине
>OVS
>Машина везет меня
При чем тут наследование? С композицией не перепутал?
>Так-что ты серешь, потому-что в реальности нет никаких объектов если материю не считать за мэш-хуйню. И существует еще пространство.
В реальности вообще не существует ничего, что можно назвать словами. Но у людей мозг устроен так, что он автоматически выделяет абстракции. Когда ты смотришь на птиц, ты сразу выделяешь абстракцию "птица", затем можешь выделить разные виды птиц, а среди них каждую конкретную птицу.
>По этому ты можешь кодить что каждый объект с лайфтайм 0 идет в мусорку. А можешь чтобы каждый объект сам себя в мусорку кидал в случаю чего.
По ООП второй подход однозначно правильный.
>Но тут уже затык в проце, он императивен и ваще многопоток не особо любит, и лезть каждый объект чтобы посмотреть чо ему самому делать поеботой попахивает.
Для подобных оптимизаций в ООП есть свои подходы, которые не рушат ООП. Это все описано в книжках по ООП.
>При чем тут наследование? С композицией не перепутал?
Можешь наследовать от волосатого мотороллера, а можешь изучать химерологию и сращивать человека с машиной чтобы у тебя не отвалился говнокод когда ты хайдишь человека и двигаешь машинку.
>Для подобных оптимизаций в ООП есть свои подходы, которые не рушат ООП. Это все описано в книжках по ООП.
Нахуй надо
Какая мне разница? Я пишу на высокоуровневом языке по его правилам. Что там конпиляторы делают меня ебать не должно.
почитай про type erasure
>Можешь наследовать от волосатого мотороллера, а можешь изучать химерологию и сращивать человека с машиной чтобы у тебя не отвалился говнокод когда ты хайдишь человека и двигаешь машинку.
Это зависит от специфики твоей доменной области. Никто кроме тебя семантики твоих классов не знает, и стурктуру наследования выбираешь только ты из своих целей.
>Нахуй надо
Для расширяемости и снижению когнитивной нагрузки.
Лютая годнота, 10/10.
Это ж чисто жавовые проблемы для обратной совместимости.
А, нихуя оказывается.
Абстракции из разряда игры в войнушку в детстве:
- Я тебя застрелил!
- Нет я тебя застрелил, у меня патроны бронебойные тебя поразили ещё за стеной!
ООП это программирование для тех кто гуманитарий головного мозга и такие вещи как функции ставят его в тупик.
И не надо рассказывать про то что А ВОТ В РЕАЛЬНОЙ ЖИЗНИ ВООБЩЕТА ЕСТЬ ОБЪЕКТЫ И КЛАССЫ ОБЪЕКТОВ ЭТО ЛОГИЧНО.
Начнем с того что нихуя это не так и элементарные частицы такие как протоны, электроны это не объекты в привычном понимании, а волны которые описываются функцией. То есть ООП принципиально противоречит физике реальных процессов, особенно на квантовом уровне.
Единственная задача ООП это ускорить верстку всякого говна и дать менеджеру понять че там под капотом без ебли мозга матаном, ведь менеджер матан не знает.
И не надо рассказывать про то что А ВОТ В РЕАЛЬНОЙ ЖИЗНИ ВООБЩЕТА ЕСТЬ ОБЪЕКТЫ И КЛАССЫ ОБЪЕКТОВ ЭТО ЛОГИЧНО.
Начнем с того что нихуя это не так и элементарные частицы такие как протоны, электроны это не объекты в привычном понимании, а волны которые описываются функцией. То есть ООП принципиально противоречит физике реальных процессов, особенно на квантовом уровне.
Единственная задача ООП это ускорить верстку всякого говна и дать менеджеру понять че там под капотом без ебли мозга матаном, ведь менеджер матан не знает.
Ты когда колбасу в магазине покупаешь, тоже пользуешься описательной системой ядерной физики?
>Это зависит от специфики твоей доменной области. Никто кроме тебя семантики твоих классов не знает, и стурктуру наследования выбираешь только ты из своих целей.
Тобишь лишь бы название ООПэ хуйни было?
Да, твоя душа это потоки энергий. И ты вызываешь абстракции и статические функции(без выделения дополнительной памяти) чтобы двигать тело и достать с кошелька 401 рубль за колбасу.
он позволяет избегать явно наследования для реализации интерфейса, и возможность при этом работать с разнвми объектами по значению, а не хранить указатели в конейнерах.
>для обратной совместимости
скорее для полной расширяемости. одна из идей в том, чтобы новая реализация интерфейса для нового типа достигалась путем одного только добавления соотвествующей функции в глобальном пространстве (имеется ввиду вне всяких классов). очень классный паттерн, очень упрощает разработку, я прям реально кайфую с него.
есть кстати очень кассный доклад кажется парента про это. он там очень подробно разъясняет за него.
напиздел, его иглбергер читал)
https://www.youtube.com/watch?v=qn6OqefuH08&t=1209s&pp=ygUTdHlwZSBlcmFzdXJlIHBhcmV0bg%3D%3D
вот еще статья на хабре почти хорошая (только там плохо объяснено зачем оно надо и почему просто внешняя перегрузка не то, что нам надо)
https://habr.com/ru/articles/706450/
Ну тогда сразу нужно говорить об принципиальной ограниченности ООП что есть некие границы применимости. Я же вижу прогеров которые говорят что ООП вообще это база, лучше этого ничего не придумали, а потом эта хуйня разбивается о простенькую квантовую механику столетней давности и о принцип неопределенности и корпускулярно волновой дуализм про который вообще в школе рассказывают.
А мне строгость языка важнее свободы, иначе бы на js писал.
Почитаю, но по-моему это как замечено чисто жаба/си детали реализации, не имеющие к обобщённому ООП отношения.
>х трусов, а тебе не извесно обработали ли запрос, нашли ли трусы твои или отдали твоему сосед
Мощно навернул
>Само же ООП-говно протиречит в том что данные вместе с кодом. В реальности
А вот в реальности-то, конечно, берём любые данные и пихаем в любой код - и он их принимает, ну надо же.
Волны в общем тоже неплохо на ООП ложатся. На него плохо ложится то, у чего нет аналогов в реальном мире. Поэтому в энтерпрайзе дохуллион притянутых за уши классов с окончаниями на -er.
>принимает, ну надо же.
Точно?Ну ок, умножил ты собаку на яблоки. Дальше что?
лично я считаю что это самый главный результат ооп) все таки как деталь свой реализации, он использует наследования, виртуальные функции и прочую оопешную радость. в плюсах еще шаблоны подключаются и вообще песня. но здесь они используются в нужном месте и очень обдумано.
короче мощь этой штуки надо прочувствовать)
Вот ты и скажи, дальше что. Может всё-таки идея хранить данные вместе с кодом не лишена смысла?
господи вот бы найти работу на с++
Имеешь ввиду что это можно использовать вместо наследования? Ну да, идея классная, хотя я просто реализую интерфейс и в рот его ебать.
ооп рак индустрии и нинужин
хуета призванная делать хуяк-хуяк и в продакшин заполоняя рынок дерьмом
знаешь эту историю про австралийский авиа-симулятор?)
>Имеешь ввиду что это можно использовать вместо наследования?
нужно)
но для этого, конечно, нужна высокая квалификация
Нет
Золотце, ты?
ходила такая байка в нулевые в плюсовых кругах)
австралийские военные поручили программистам создать высокоточный авиа-симулятор для обучения пилотов. чтобы там с пво, которое по ним стрелять может. короче прям вот полный симулятор военного пилота.
программисты были большими поклонниками ооп, сделали качественную, хорошо продуманную иерархию наследования. они уложились в сроки с небольшим запасом и от нечего делать в них сыграло национальное чувство: "как так, мы же австралийцы, а ни одного кенгуру на всей карте местности нет!". до сдачи оставалось не так много времени, поэтому на скорую руку class Kangaroo был публично отнаследован от какого-то супер базового класса. затестить не успели, но доп класс ничего не должен был сломать, так и отдали военным.
какого же было удивление первых пилотов, когда после взлета кенгуру рассредоточились по местности и начали херачить по ним из стингеров...
как стать гордым плюсовиком?
мимо жабапидор
ну кстати тут сыглы, лаконичный си в тысячу раз лучше
Кукарекание неосилятора
Звучит как байка для малосведущих в разработке =(
да тихо тихо, я сам за плюсы всей душой. просто картинка смешная.
я кстати смотрел этот ролик, там довольно смешная аргументация в духе "очень длиные названия static_cast, reinterpret_cast, ..." и "тупые неймспейсы, очень длинно получается a::b::c::fuck::you::.."
>НАСТОЯЩИЙ ПРОГРАММИСТ конечно же может двадцать мегабайт идеально оптимизированного лапшекода в голове держать. Ему никакие абстракции не нужны, они только производительность снижают.
Погромист не сможет.
А любая нейросетка легко.
И ей не нужны эти объекты и абстракции.
Нейросетка хоть с 5000 "go to" код напишет и не запутается что где и куда.
И ей не нужен твой сраный рефакторинг - если что то изменится - проще еще раз сгенерировать новый код - это же занимает несколько секунд/минут.
Ты не можешь описать электрон объектом в ООП. Потому что электрон не детерминирован в пространстве и времени, у него нет конкретных координат.
Более того электрон может одновременно находиться в разных состояниях. Это буквально противоречит ООП.
а зачем держать в голове лапшекод? kiss
Но может описать модель электрона
теперь код не представляет ценности - теперь ценность это хорошее и полное техзадание
а у большинства вместо техзадания - говно на салфетке, текстовый файлик и E-mail от заказчика со словами "быстро и красиво запилите мне"
Норм, если про SOLID не забывать. C# последней версии довольно удобен. Можно в интерфейсах прямо дефолтную имплементацию прописывать, навешиваешь интерфейсы на класс и допиливаешь по мелочи.
Ну давай попробуй. Какие свойства есть у электрона, перечисли?
Хорошая вещь, годная. Занимайся.
Положение и заряд, ну или масса.
Мы вам перезвоним
Спин забыл
А импульс есть?
Ну когда он летит куда-то?
c# заебись, там правда давно ООП никто не пользуется
Почитал твоей мамке за щеку, проверяй.
А чем там пользуются? Пиздой твоей мамаши-шлюхи?
>Само же ООП-говно протиречит в том что данные вместе с кодом. В реальности например берем любую форму учета, мы бланк формируем заполняем в него операцию, после преобразуем данные с него в базу(журнал-ордера, главную книгу) и работает с данными. А не запрашиваем каждый раз первичный документ.
Данные у тебя лежат в ДТО классах, а бизнес логика в сервисах.
>Ну и сама калопсуляция по сути хуйня в реальности тоже не существует в итоге чтобы бочка наследуемая от бокс не двигалась ей добавляют 60тонн весса, вместо создать текстурку с колизей и мэшами.
Смешал теплое с мягким. Инкапсуляция про объединение свойств и функций в объект, а наследование про расширение функционала без изменений для существующего объекта. Алсо давным давно придуманы интерфейсы, которые решают описанную тобой проблему. + ты можешь переопределять свойства в наследуемых объектах, поэтому если тебе нужно докидывать 60тонн весса - это значит, что ты хуево расширяемый класс написал.
Самое говно в том, что оно неправильно понято в Java, и теперь эти ебаные Java программисты со своим Spring Framework отравляют своей хуитой индустрию. Ехал блядь сервис из 3 строчек через 5 слоев пустых абстракций. Надеюсь, ИИ заебется ковыряться в этих нагромождениях и поделит долбоебов на ноль.
создаёт больше проблем чем решает. Когда дело касаетс проблем наследования то начинаются неоднозначные решения
>60тонн весса - это значит, что ты хуево расширяемый класс написал.
Да? А я тумал ООПэ хуйня как в реале и а оказалось надо тики сервера жрать чтобы летающую корову в небе прихуярить?
Как писать по ООП на голенке?
Описываешь состояние, навешиваешь на это состояние поведение. В чем у тебя вопрос?
вот так пись-пись-пись
Ну как это примерно выглядит? У меня щас есть веб-сервер, где в ручках описана логика, и в ней же вызываются функции из синглтонов (например круды из бд), типа такого:
func randomHandler(somevars any...) error {
huynya := db.GetHuynya()
processed := huynya +=1
writer.Response(processed)
return nil
}
Ручки в main подключаются
Достаточно ооп-шно?
Выбираю ооп для малых проектов - удобно, структурировано, понятно!
Для больших ни в коем случае, это же пиздец, через год откроешь свой большой проект и ещё год будешь разбираться как всё работает, ну его нахуй
Лучше процедурное программирование
Для больших ни в коем случае, это же пиздец, через год откроешь свой большой проект и ещё год будешь разбираться как всё работает, ну его нахуй
Лучше процедурное программирование
>в ручках
Хррртьфу в ебало.
>типа такого
У тебя здесь нет состояния.
>Ручки в main
Хррртьфу в ебало еще раз.
>Достаточно ооп-шно?
Ну, ООПшным у тебя может быть сервис для работы с базой данных, например. Я хз че ты хочешь в принципе.
Терпи, хуесос
>теперь код не представляет ценности
Код, который пишут модели, не представлял ценности и раньше. Рефакторю после каждой таски, сколько бы кейсов я ни пытался засунуть в AGENTS.md
Что можешь сказать про него, анон?
Планирую всерьёз заняться изучением с 15.05.2026.