Я лично в более широком смысле, не только относительно программирования пришел к тому, что если что-то на длительном промежутке времени в конкурентной меритократичной среде стало популярным и успешным - значит оно достаточно хорошо и качественно решает какую-то реальную проблему, при этом как эта проблема сформулирована и детали реализации особо не важны и не надо ими забивать голову, может быть осознаешь их когда будет больше знаний и опыта.
У всего есть своя сфера применения. Программированию как таковому десятилетия, за это время миллионы неглупых людей съели миллионы собак и выработали подходы к разным проблемам, в зависимости от того какую задачу и как нужно решить - т.н. парадигмы программирования.
Один из таких подходов - ООП, другой - функциональное программирование, третий - декларативное программирование, и т.д.
Современные языки программирования общего назначения как правило включают в себя элементы нескольких парадигм, имея в основе ООП. Как и почему так вышло? Да хуй его знает, вышло значит так надо. Изучай актуальные технологии и лучшие практики и не забивай голову философией, объяснений ты все равно не поймешь пока несколько лет не проработаешь в индустрии.
Просто я не вижу особой разницы в создании обьекта. Например FileStream, вместо использования File. Это же куда проще, когда не нужно создавать экземпляры. Разве нет?
Чем больше система, тем глубже должна быть систематезация. Для мелких проектов ооп нах не нужно, но в больших с ним проще, чем без него
> я читал про классы и обьекты и так и не вкурил, зачем нужно создавать экземпляры класса
Попробуй поразмышлять с позиции разработчика игр, чтобы понять ООП.
Каждая сущность в игре - экземпляр класса. Методы ей нужны, чтобы взаимодействовать с окружающим миром. Допустим, есть какой-нибудь зомби, у него внутри хранится количество здоровья. Чтобы нанести урон зомби, тебе нужно вызвать метод TakeDamage. Через этот же метод ты можешь передать информацию о том, что у тебя зачарованное оружие, которое поджигает врагов, после чего зомби загорится.
А ещё у тебя будет игровой цикл в котором ты будешь обновлять все сущности:
for (int i = 0; i < entities.length; i++)
entities.Update(deltaTime);
for (int i = 0; i < entities.length; i++)
entities.Render();
Это примерно как "зачем парикмахеры стригут двумя-тремя разными машинками с разными насадками и несколькими видами ножниц, если можно ебануть одной машинкой под 3 мм?"
Ну ты понял.
>Да хуй его знает, вышло значит так надо.
Обана. Карго-культист попался. Верун в авторитеты. "Путлер хуярит ядеркой - нулана - ну значит такнада".
А когда у тебя в руках молоток, все предметы кажутся гвоздями.
>сли что-то на длительном промежутке времени в конкурентной меритократичной среде стало популярным и успешным - значит оно достаточно хорошо и качественно решает какую-то реальную проблему, при этом как эта проблема сформулирована и детали реализации особо не важны и не надо ими забивать голову, может быть осознаешь их когда будет больше знаний и опыта.
Ну вот представь, у тебя есть 50 объектов "электродвигатель" в проекте, которыми надо управлять одинаково.
Очень быстро ты обнаруживаешь, что из одного дискретного сигнала "вкл/выкл" образуется небольшой адок из статических и динамических состояний. Например:
1. Выключен. (нет команды, нет сигнала обратной связи от контактора, нет сигнала од датчика оборотов)
2. Включается (есть команда, ждем сигнал контактора, ждем ОС от датчика оборотов)
3. Авария включения по контактору (таймер вышел, контактор не замкнут)
4. Авария включения по датчику оборотов...
У тебя все еще не возникло желание написать класс объекта Motor?
Когда в последний момент окажется, что ты забыл про аварию по сигналу от датчика тепловой защиты, и его надо добавть во все 50 кусков твоего статического кода, тогда такое желание точно возникнет. Но будет поздно, и не в этом проекте.
>интернетом
Отрубило интернет - накрылись все движки.
Г - отказоустойчивостью
>на каждый двигатель по контроллеру с интернетом
вот тут то тебе первый попавшийся мимо-студентик, сканирующий сетки nmap промышленную револющию и устроит
мимо-мамких хакер
техпроцесс в "облаке" - это как жопа в ломбарде
>поставлю на каждый двигатель по контроллеру с интернетом и буду апдейтить один и тот же код 50 раз
Проснись, ты обосрался.
Сименс как раз на такой ебучий случай реализовал ООП даже в контроллерах.
"Урок 3
Введение в HMI Faceplate
HMI Faceplate – это графический интерфейс типового устройства, например, датчика давления или регулирующего клапана.
Фейсплаты поддерживаются комфортными панелями оператора SIMATIC HMI Comfort Panels.
Фейсплаты конкретных устройств являются экземплярами (потомками) шаблона (предка).
В комфортных панелях таким шаблоном является тип данных Faceplate.
Потомки наследуют свойства своего предка, пока существует родственная связь между ними.
Если эту наследственную связь разорвать, то потомки становятся независимыми от шаблона, из которого их сотворили.
При наличии родственной связи экземпляры воспринимают все изменения своего предка даже после своего рождения.
Для наглядности будем называть разработчика HMI – конфигуристом, а разработчика программы PLC – программистом.
Рассмотрим процесс взаимодействия программиста и конфигуриста при разработке HMI для 100 типовых регулирующих клапанов на панели оператора в TIA Portal V14 для контроллеров старых серий S7-300/400 (процесс создания фейсплат для контроллеров новых серий S7-1200/1500 подробно рассматривается в уроке 5):
Программист разрабатывает PLC data type (тип данных ПЛК), который отражает связь данных между HMI и PLC.
На основании PLC data type конфигурист в библиотеке проекта разрабатывает Faceplate type (шаблон).
На основании шаблона конфигурист создаёт 100 экземпляров фейсплат для 100 клапанов.
На основании PLC data type программист создаёт 100 блоков данных, через которые программа PLC будет взаимодействовать со 100 фейсплатами.
Конфигурист создаёт HMI user data type со структурой, копирующей структуру PLC data type.
На основании HMI user data type конфигурист создаёт 100 HMI tags, связанных с блоками данных, созданных программистом на шаге 4.
Конфигурист привязывает 100 фейсплат к 100 тегам HMI (которые в свою очередь привязаны к блокам данных ПЛК).
Если теперь изменить в шаблоне-предке, например, цвет закрытого клапана, то во всех 100 фейсплатах-потомках цвет закрытого клапана также изменится.
Если на одном ПК в проекте уже есть шаблон с фейсплатами-потомками, то уже не получится привязать эти фейсплаты к другой версии этого шаблона, созданной на другом ПК.
В одном из следующих уроков рассмотрим, как это делается в TIA Portal. "
https://www.maxplant.ru/article/siemens_tutorial_3.php
>че ты хотел сказать в скада уже клас мейн и массив с флагами дальше сервис лаер микросервисы там уже ооп классы данные функции но они никак не связаны с электродвигателями там только формулы.
https://www.youtube.com/watch?v=9HptYhedYMs
Колбасный фарш забыли спросить.
>Чтобы нанести урон зомби, тебе нужно вызвать метод TakeDamage
Вызываю TakeDamage(Zombie, damage) вместо Zombie.TakeDamage(damage) и всяких объектов и наследования, что ты мне сделаешь?
Ты в одном посте умудрился нахуевертить целую кучу самых говеных антипаттернов, очевидных любому, кто хоть немного занимался разработкой хоть игр, хоть просто сколько-нибудь сложных систем.
И да, в геймдеве не используется объектно-ориентированное моделирование, с добрым утром.
Сейчас так фактически и происходит. Обработку данных выносят в синглтон сервисы, которые по сути являются более гибкой версией статик классов, а класс используют просто для хранения состояния.
Молодец, ты только что изобрел то, во что у тебя компилятор превращает, изобреталель ecx this блеять
ну типо вот создаешь ты игрушку, есть у тебя класс "солдат", а у тебя стратежка, тебе надо 10 солдатов. вот и создаешь ты 10 экземпляторов. понятно что это энциклопедический пример. и в жизни все сложнее, но суть такая, а как применить уже зависит от проекта. о чем вообще говорить когда сейчас везде ioc/di, а это огромная глобальная свалка объектов которые ты достаешь когда они тебе нужны.
>понятно что это энциклопедический пример
...того как делать нельзя, иначе получится неподдерживаемая лапша. Но мы же на харкаче, понятно, какой тут уровень.
> Сап программач. Изучая различные источники я читал про классы и обьекты и так и не вкурил, зачем нужно создавать экземпляры класса и через него вызывать методы, нежели все обьявить в статик и не мучаться с созданием экземпляров?
Они и не нужны. Вон Линукс вообще без петушиного ООП написан.
Вообще наверное 99% usecase именно ООП - это разнообразный ORM.
Большая часть коммерции - это в основе базы (карточек товаров, складских запасов, пользователей и т.п.) - и в программировании такие сущности легче и логичнее всего обрабатывать как объекты.
Где-то читал, они там реализовывали виртуальные методы, лень искать. Так что пришлось велосипедить костыльное ООП на Си.
Там вроде какие то костыльные деревья используются. Вообще, если рассматривать создание обьектов то в этом есть небольшой смысл. Хотя лично я бы сделал создание обьектов не на прямую из программы, а создавать каждый конфиг файл по отдельности. Мне кажется так будет удобнее
Ты только что Си.
struct Rect rect1;
struct Rect rect2;
init_rect(&rect1, 0, 0, 10, 10);
init_rect_from_rect(&rect2, rect1);
struct Rect rect3;
rect3 = intersect_rect_with_rect(rect1, rect2);
struct Circle circle;
char flag = 0;
intersect_rect_with_circle_safe(rect3, circle, &flag);
>Попробуй поразмышлять с позиции разработчика игр
ECS
C
S
И ооп идет нахуй.
Посчитай количество игр на ООП и на ECS, и станет ясно, что на хуй идет ECS.
Ну так в играх ООП не настоящее, а тупо какой нибудь одноранговый глобальный массив.
>Посчитай количество игр на ООП и на ECS
На ECS на порядок-два больше.
>Так что пришлось велосипедить костыльное ООП на Си.
Почему пришлось то? Зачем? Кто-нибудь может сможет наконец ответить на вопрос треда "Зачем ООП нужен" ?
А если написано формально на ООП языке, но наследование не используется, а используется композиция?
ОП частично ответил на свой вопрос. Вообще зависит от реализации - "а нахуй оно нужно". Например используя статический File. Writeallbytes() вроде бы оно и заебись, однако FileStream дает некоторые возможности. Например задать какие нибудь атрибуты файлу и т.д. конечно это не самый лучший пример, т.к. статические методы все еще кажутся "лучше". Еще один пример и он более годный т.к. наглядный - использование винформ а так же контролов. Обьекты сами по себе нужны для большой модульности. Чтобы не переписывать одно и тоже. Допустим у нас есть контрл "батон". И этих батонов мы можем напиздячить сколько угодно, при этом их можем изменить. Статик же не позволит создавать обьекты, и будет выглядеть не правильно. Тут же мы создаем обьект, можем раскрасить кнопку, изменить текст и т.д. Вообщем, понимать суть "обьектов" достаточно трудно ибо годных обьяснений и "а нахуя это нужно" особо нету.
Насколько я знаю, на бытовом объекты разделяются по принципу границ, разграничения... Ну например: стол, он ограничен поверхностью дерева, на границе с воздушной средой, человек ограничен кожей. Конечно это переупрощение... Например кастрюля без крышки является тонким листом металла, надо вводить еще виртуальную поверхность. Дальше, мы как-то должны различать один объект от другого, а еще объединять объекты в другой объект (ну, мы же объединяем волосы в объект борода), сравнивать их свойства, давать им названия.
Кажется, этим занимается https://ru.wikipedia.org/wiki/Онтология_(информатика)
Инкапсуляция тут не нарушается. Наружу так же торчат геттеры/сеттеры, а в сервисный слой передается объект. Вынос логики в сервисы нужен для соблюдения принципа единственной ответственности.
Кек, блять. Хуею с местных философов. А если это что-то бестелесное? Например, у тебя объект Message - где у него поверхность?
А кто сказал, что есть отличия? Отличия есть только в сумеречном мире ОПа. Он почему-то думает, что вся обработка данных объекта должна находится в рамках класса, но это не так. Формулировка "Инкапсуляция это хранение данных и методов их обрабатывающих в одном месте в пределах класса" ошибочна. Инкапсуляция это когда у тебя данные отделены от интерфейса, который предоставляет класс. Например, у тебя есть класс Book в котором есть List<Page> наружу будет торчать интерфейс readPage(index), а все остальные действия со списком Page для потребителя будут закрыты. Потребитель даже не знает, хранишь ты эти Page в списке или где-то еще. Это и есть инкапсуляция.
Ну анон, даже в вики про это упомянуто. Не надо демагогией то заниматься.
Например, у слов есть граница в виде пробелов, и так далее.
>Формулировка "Инкапсуляция это хранение данных и методов их обрабатывающих в одном месте в пределах класса" ошибочна
Это как раз букварная формулировка, а то что ты рассказываешь - это абстракция.
Звучит как буллщит, потому что для обработки тебе нужны какие-то знания о внутреннем представлении объекта, а значит либо дырявый public и любой может зайти на задний двор, или клоунский friend.
Нет не нужны. Для работы с объектом тебе нужен интерфейс, который он предоставляет и это все.
Значит, реальная обработка будет внутри объекта, как оно и есть в обычном ООП.
Боже, какие блять тупые итт. Да, абстракция тесно связана с инкапсуляцией. Это как раз отделение абстракции от реализации.
>инкапсуляция предназначена для изоляции контрактных обязательств абстракции (протокол/интерфейс)
https://ru.wikipedia.org/wiki/%D0%98%D0%BD%D0%BA%D0%B0%D0%BF%D1%81%D1%83%D0%BB%D1%8F%D1%86%D0%B8%D1%8F_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)
>букварная формулировка
Это устаревшая букварная формулировка из книги 2005 года. Тогда еще не было клин кода и дрочева на солид.
Нет не будет. Что ты подразумеваешь под реальной обработкой?
Ты мне на собесе даешь такую формулировку, я у тебя спрашиваю: "Каким образом в таком случае ты планируешь обеспечить принцип единственной ответственности для этого класса? Допустим у нас есть класс Employee. Отдел HR хочет знать в каких активностях он когда либо участвовал. Бухгалтерия хочет посчитать для него зарплату исходя их количества отработанных часов и часовой ставки. Руководитель хочет получить связанные с ним события прихода и ухода с работы. Ты собираешься реализовать все эти методы в этом классе? Но ведь тогда у тебя будет больше одной причины для его изменения." Твои действия?
>инкапсуляция предназначена для изоляции контрактных обязательств абстракции (протокол/интерфейс)
Ну вообще-то "предназначена" != является.
В англ. вики вообще так:
Encapsulation allows developers to present a consistent and usable interface which is independent of how a system is implemented internally
Я склоняюсь к тому что это просто хуевый перевод.
>Это устаревшая букварная формулировка из книги 2005 года
Ну а про интерфейсы вообще хуй пойми откуда.
SOLID к слову в 2000 году сформулировали.
Любую. Ну например конкатенация строк. Никак ты ее не сделаешь в сторонней сервисной функции, если только видишь внутреннее устройство строки. Поэтому логичнее иметь конкатенацию методом класса строка.
Сформулировали в 2000, а популярным стало после выхода Clean Code в 2007
Если так делать, до можно довести до абсурда и утверждать, что в каждом классе должен быть всего 1 метод.
>Ты мне на собесе даешь такую формулировку, я у тебя спрашиваю: "Каким образом в таком случае ты планируешь обеспечить принцип единственной ответственности для этого класса
Пиздец сегвей. Какая связь вообще со словарным определением инкапсуляции, лол?
Какое-то буквоедство если честно.
>Твои действия?
Хуй его знает, я сам 9 месяцев назад вкатился лол. Мне по работе SOLID особо не вперся, я просто делаю примерно как уже было сделано до меня и исправляю после правок сеньора-помидора (если таковые имеются).
По уму-то наверное надо IEmployee делать с общей инфой, или абстрактный класс, и от него уже наследовать EmployeeHR, EmployeeAccounting, EmployeeManagement и т.п. для разных потребителей с нужными полями и методами, и соответствующие запросы к базе и маппинг писать.
А вообще сильно зависеть будет от того как это все в базе хранится, как оттуда дергается, как уже реализованы подобные темы в существующем коде и т.п. - может получится что эта информация уже другим запросом параллельно и так дергается, а я второй раз буду в базу долбиться. По тикету короче смотреть надо конкретную задачу, а не по примерам таким в вакууме.
Адаптеры с утилитарными методами в виде оберток над примитивами изначально были идеей не очень и в последствии пришлось пилить всякие StringUtils и NumberUtils в jave, например. Но твой пример в целом неудачный, потому-что это по сути даже не полноценные объекты, а просто как я выше написал адаптеры к примитивам с утилитарными методами обработки.
>Пиздец сегвей. Какая связь вообще со словарным определением инкапсуляции, лол?
Ну ты же должен и инкапсуляцию соблюсти и SRP. Как ты это сделаешь следуя своей формулировке?
>По уму-то наверное надо IEmployee делать с общей инфой, или абстрактный класс, и от него уже наследовать EmployeeHR, EmployeeAccounting, EmployeeManagement и т.п. для разных потребителей с нужными полями и методами, и соответствующие запросы к базе и маппинг писать.
Мы тебе перезвоним.
Ну понятно, уволены из объектов в примитивы.
А по мне так примитивы - это недообъекты где забыли сделать приватность.
Блять, читайте классику, неучи. https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html Там пример прям тот, который я вам итт давал. Мне не верите, так дяде Бобу верьте.
Представь себе что у нас есть просто String, как набор байт, и PackedString, как в с++, когда длинная строка это указатель на массив, а короткая (до 8) хранит байты прямо вместо указателя. Это деталь внутренней реализации.
Теперь если мы делаем внешний StringUtils который конкатенирует строки, мы можем только выделить новую строку размером под сумму наших, а PackedString придется ее потом переупаковывать обратно - всегда оверхед. Либо мы сливаем StringUtil детали реализации, нарушая инкапсуляцию. При этом таких проблем нет если конкатенация внутри самой PackedString, потому что она знает детали реализации и сама умно выберет, выделать память или упаковать.
Предположу, что ты промахнулся ответом, или не понял что тебе написали.
Промахнулся, но суть не в этом. Ты тоже долбоеб, влез со своими нерелевантными обертками. У них в принципе не может быть причин для изменения. Речь идет о классах, которые ты будешь писать для решения бизнес задач.
Ну собственно в этом и заключается проблема. Теперь ты жестко привязан к внутренней реализации и тебе надо залезть внутрь класса чтобы что-то поменять. Это еще и опен-клозед нарушает. Алсо, в джаве строки и так иммутабельные, если что.
> Теперь ты жестко привязан к внутренней реализации и тебе надо залезть внутрь класса чтобы что-то поменять
Так в данном случае это плюс, а не минус.
А иначе у тебя фабрика через фабрику и боксинг анбоксинг на каждый чих.
>Алсо, в джаве строки и так иммутабельные
Мертвый язык.
Согласен, в данном случае да. Тут важно помнить, что solid это не серебряная пуля, нужно помнить зачем он вообще нужен. Спор вообще был о том, что определение инкапсуляции как хранения данных и методов в пределах класса устарело. Ну как бы два стула: либо оно устарело и не отображает текущее положение вещей, либо solid противоречить базовым принципам ООП, в частности нарушает инкапсуляцию.
Ты разве что обоссаться на интервью от страха можешь, чмоня. Не преувеличивай свои возможности. Так что ты имеешь сказать в итоге на статью дяди Боба, уеба?
Дядя - умный инфоцыган, и писать правильное решение загадки он не стал.
Чел, примеров реализации принципов солид хоть жопой жуй. Завали уже ебало, хватит позорится. https://muatik.medium.com/oop-solid-with-examples-d3dc310d72c3
Покажи где конкретно у дяди Боба в статье сервисный слой.
У дяди боба не може быть сервисного слоя, потому что сервисные слои в анемичной доменнойя модели, а у дядя боба рич модель.
Ну я доябываюсь потому что ты пишешь:
>Почитай дядю боба
>Методы надо в сервисном слое хранить, а не в классе.
>неучи
А потом оказывается что у дяди Боба ничего про сервисные слои, это вообще другая модель, надо просто поверить...
>TakeDamage(Zombie, damage)
А если у зомби резисты какие-то есть к дамагу, которых нет, например, у Mutant уникальная логика в одинаковом методе у похожих объектов? Будешь на каждый тип моба метод с префиксом/постфиксои писать? А если у тебя этих объектов под сотню?
https://blog.inf.ed.ac.uk/sapm/2014/02/04/the-anaemic-domain-model-is-no-anti-pattern-its-a-solid-design/
Так можно допиздеться до того чтобы каждый метод и каждое поле в своем отдельном классе хранить. Колесо провернулось, ДВАЧ ЗАЧЕМ НУЖНЫ ОБЪЕКТЫ?!
SOLID - это принцип, и рекомендация. В отличие от инкапсуляции, которая есть буквально один из признаков и элементов словарного определения ООП, и которой SOLID кстати не противоречит примерно никак.
Так же как например буклет по ораторскому искусству не противоречит звуку которому соответствует буква А.
Так наверно 99,999% проектов на всех ооп языках такую модель имеют. Как только кто-то говорит в начале проекта, а давайте сразу будем рич модель, DDD вот это все, тут же начинается "Да сильно сложно, у нас мало времени до релиза"
Ну и сейчас стала неактуальна с микросервисами эта дилемма.
Потому что объект это как живое существо, у него есть данные которые он инкапсулирует, и методы, т.е. ты ему можешь сказать что нужно сделать, а он тебя поймёт если у него есть этот метод.
Если у тебя методы отдельно а данные отдельно, то не достигается инкапсуляция, считай как ты вскрыл человека и засунул ему еду в желудок и вытащил дерьмо из кишечника, а он сам должен жрать и срать. Т.е. говоря более обще, объект это инкапсуляция, а инкапсуляция это автоматизация, т.к. ты же не хочешь бегать вокруг человека и лазить ему в анус, тебе надо чтобы человек сам себя обслуживал, вот тут принцип тот де.
> И да, в геймдеве не используется объектно-ориентированное моделирование
https://youtu.be/1cTV459gg4s
Причём забавно, что микросервисные архитектуры подошли ближе к тому самому ооп, нежели то как принято сейчас писать на джаве, шарпе и тем более крестах. Микросервис это тоже своего рода объект, только инкапсуляция в нём форсится гораздо жёстче, т.е. чтобы сделать его действительно инкапсулированной сущностью не нужно даже напрягаться, проявлять какую-то дисциплину и т. п. (ну на самом деле нужно, чтобы не раздувать сервисы до размера монолитов), всё как бы само происходит.
Эту статью дядя Боб написал? Нет?
Напомнинаю что ты писал
>Почитай дядю боба
>Так что ты имеешь сказать в итоге на статью дяди Боба, уеба
А потом начались маневры.
Толоконный лоб.
Пошел Боб по базару
Посмотреть кой-какого товару.
Навстречу ему программист Балда
Идет, сам не зная куда.
«Что, Боб, так рано поднялся?
Чего ты взыскался?»
Боб ему в ответ: «Нужен мне умелец:
фронтендер, бекендер и за сервером сиделец.
А где найти мне такого
Работничка не слишком дорогого?»
Балда говорит: «Буду служить тебе славно,
Усердно и очень исправно,
В год за три щелка тебе по лбу,
Есть же мне давай вареную полбу».
Только вот в большинстве случаев, если копнуть, это оказывается сервис ориентированная архитектура, а не микросервисы. Так что ничего не изменилось.
Но как по мне это костыли какие-то. У тебя есть один класс - надо что-то в него добавить и вместо того чтобы просто в него доьавить функционал ты городишь костыль сбоку.
Так объясни нормально вкатуну почему не дополняют существующий класс, а делают другой на его основе с новым функционалом.
Чтобы у тех, кто пользуется оригинальным объектом, — ничего не поломалось?
Только причем тут уточнение на основе?
OCP принцип применяется совместно с принципом prefer composition over inheritance. Наследование часто убивает пользу от OCP.
То есть чтобы правильно следовать принципу OCP ты заблаговеременно должен создать расширяемый код, чтобы в него можно было заинжекнить другой клас модифицирующий поведение
Идеальная ситуация когда ты только добавляешь код, не трогая уже написанные класы
> Чтобы у тех, кто пользуется оригинальным объектом, — ничего не поломалось?
А как оно поломается, если ты доьавляешь новые функции в класс, не трогая при этом старые? Зачем наследование делать то?
>>2629265
Более простыми словами объясни, желательно с примером
https://pastebin.com/raw/3XT4vaUA
Ты все равоно не поймешь без практики. OCP это достаточно абстрактный принцип, одним примером не поянишь.
Вот здесь ты вместо того чтобы изменять код HelloPrinter когда тебе нужен новый тип приветствия, ты создаешь новый класс Helloworlder и передаешь его в конструктор HelloPrinter. Благодаря этому ты не заботишься, что поломал код, который испоьзует старое приветствие.
> не мучаться с созданием экземпляров
А что вместо этого создавать? Struct/record? Мучений меньше станет?
Вместо одного класса получилось пара десятков на каждый чих.
Ты не понимаешь. Для адептов ООП Чистый Код это как Далекие Берега, куда воины попадают после смерти на поле сражения. Таже для адептов ЧИСТЫХ ФУНКЦИЙ лямбда-исчисление это Совнгард где они их ждет Тьюринг с Чёрчем
>Получается что вместо класса Игрок
Осталось только пригласить твоего лечащего врача, чтобы понять, почему в твоей голове получается именно так.
>>2630323
Потому что я посмотрел примеры OCP в интернете. И эта хуйня выглядит именно так. Вместо одного класса PersonStorage, в котором хранилось 2 ( во втором случае добавили еще 1 метод, но не суть) метода, а в этом же коде по стандарту OCP уже высралось аж 4 класса по 1 методу.
Нахуя это все надо? Зачем тогда вообще вам классы нужны, если вы в них хуячите только по 1 методу? Чем это тогда отличается от обычных одиночных функций? Хули тогда не сделать просто 3 функции PersonDB, PersonJSON, PersonXML?
> Игрок с методами стрельбы
Поймешь, когда попробуешь сделать разное оружие, например автомат и гранатомет, да еще чтобы можно было его бросать на землю и подбирать, а потом захочешь ввести нового персонажа с двумя оружиями.
>с методами прыжка
И когда будешь делать противников, начнешь везде копипастить код прыжка.
Глядишь так и до композиции, а там и ECS додумаешься.
> Вместо одного класса PersonStorage, в котором хранилось 2 метода
Проблема в том, что такой класс должен уметь и файлы открывать, и к базам данным коннектиться, а то и к интернету.
Если такой класс в библиотеке, а мне нужна только запись в файл, мне все равно придется тащить в прогу либы для баз данных, когда они мне нахуй не нужны. А это не только вес, но и дыра в безопасности.
>Чем это тогда отличается от обычных одиночных функций?
Полиморфизмом.
Потому что ты вызываешь person.save() и оно само выберет основываясь на person. В твоем же случае тебе надо городить
if person is PersonDB:
personDBsave(person)
elif person is PersonJSON:
personJSONsave(person)
elif person is PersonXML:
personXMLsave(person)
>Если такой класс в библиотеке, а мне нужна только запись в файл
Ну это уже проблема сторонних библиотек. Но мы говорим же про свой код.
>Потому что ты вызываешь person.save() и оно само выберет основываясь на person.
Каким боком? Тебе в save также надо будет писать if elif elif elif... Так в чем разница?
Ты дебс? Цимес не в том сколько в классе у тебя методов. Ты по проекту размазываешь один метод или функцию. Потом тебе хочется изменить работу этой функции в каком-то аспекте. У тебя варианты.
1. Модифицировать эту функцию. И перетестировать решительно нахуй все что от этой функции зависит.
2. Изначально сделать так чтобы эта функция в нужно аспекте делегировала работу другому коду. Тогда она не будет зависет от аспекта и перетестировать не нужно. Это можно все и без ООП релизовать только будет куча бойлерплейта. В разы больше чем с динамическим полиморфизмом в ООП
Ну ты точно не очень умный. Я тебе пример приводил, где ты меняешь поведение в месте использования, а не в самом классе.
>ебе в save также надо будет писать if elif elif elif
Нет, ты же скинул сам 2й скрин где этого нет. Каждый класс умеет только одно.
Да схуяли у тебя должно что-то сломаться? Вот решил ты в классе PersonStorage поменять метод save_to_json. Схуяли у тебя из-за этого должен вдруг сломаться метод save_to_database?
Очевидно, что это делается в другом месте отдельно. Тут приведен пример OCP, а не вся рабочая программа же.
Зачем тогда тебе класс?
Делай отдельные функции для сохранения в жсон и в базу. В реальном проете у тебя копипаста как снежный ком будет расти в таком случае
С того, что ты мог поменять какую-то переменную person_state, которая может читаться в том методе.
Что-нибудь типа person_data_length, к примеру. Реальный случай был такой в какой-то с++ либе.
>Нигде не делается.
И каким хуем у тебя определяется во что сохранять - в db, json или xml?
>Зачем тогда тебе класс?
>Делай отдельные функции для сохранения в жсон и в базу.
Так я это и спрашиваю - чем ваш OCP принцип отличается от отдельных функий, если вы его и так дробите класс на 100 дочерних классов с 1 методом.
Это все равно надо как-то где-то через if elif прописывать.
Классы не тольк методы имеют, они еще данные инкапсулируют с которыми эти методы работают. А так вообще классы в основном используются как типы + динамическая диспечеризация методов
Нет, если я использую только XML в данной программе, зачем мне создавать других персонов? Или это может из конфига загружаться без всяких if.
Кармак как-то обходился без классов когда делал дум и квейк.
А почему Кармак не писал движки на языке, в котором были бы классы? Зачем он сидел на С, когда уже был С++?
>Либо не было компилятора
Как его не может быть? С++ появился в 83, а игры он делал в 90-е.
>либо не умел
Да, лучший программист всех времен не освоил классы в С++ и поэтому сделал свои собственные. Звучит логично.
>Как его не может быть?
Ну вот так. Может не купил его.
>Да, лучший программист всех времен
Так Торвальдс на Си пишет.
>не освоил классы в С++
Срармак мог и не освоить, где он там алгоритмы 3д украл, могли не объяснить.
Скажи спасибо что не фортране написал и ладно.
>Срармак мог и не освоить, где он там алгоритмы 3д украл, могли не объяснить.
>Скажи спасибо что не фортране написал и ладно.
Пиздец хуйню высрал и рад.
Классы тормозят и жрут память, а он не был макакой как современный скам вроде тебя. Это сейчас макакам плевать на производительность, главное чтобы проще было говношлепить говнокод, а тогда программисты так не думали, особенно в играх где каждая инструкция важна.
Живые организмы жрут энергию! Какой позор! Срочно всем превратится из живых в неживые, чтобы востановить вселенскую гармонию!
Ну и зачем ты оправдываешь говнокод тактами процессора? Ты мазохист?
Так крестам многие копротивлялись не потому, что ООП - это плохо, а потому что кресты - говеный язык. Но тем не меннее, с ростом сложности проектов, взвесив все плюсы и минусы, большинство переползло на Си++, в том числе и Кармак.
Был бы говнокод, DOOM бы просто не пошел на компьютерах на которых шел.
Чего? Это общеизвестный факт что он просто переписал алгоритмы с научных пейперов по 3д из вузика.
Кресты говеный только по сравнению с современными языками, которых тогда и не было либо они были невменяемо тормознутыми.
По сравнению с си - это как полет в космос.
Просто компиляторы были тупые. Сейчас классы практически ничего не жрут и не тормозят.
Ты просто не сталкивался с сектой фанатов Кармака-величайшего погромиста, которые верещат как он изобрел вообще чуть ли не все на свете.
>Сейчас классы практически ничего не жрут и не тормозят.
Потому что мощность компьютеров сейчас настолько высока, что эта разница стала незначительной. Но раньше компьютеры были слабые, плюс игра в софтварной эмуляции, без специализированных аппаратных ускорителей. То что сейчас практически незаметно, тогда имело серьезный вес. По хорошему надо было писать на ассемблере, но всё же сложность уже не та как в 2д, так что Кармак взял ближайшую альтернативу - Си, это максимальная уступка, дальше уступать в сторону С++ уже смысла нет, ведь уровень ведь абстракции првактически такой же, однако будет потеря производительности из за крестового говна в виде объектов и прочего.
>>2630979
Если это задача такая хуйня простая - почему это никто не сделал раньше? Сводить все заслуги Кармака к да он просто пару формул спиздил - это пиздец отбитым надо быть.
> По хорошему надо было писать на ассемблере, но всё же сложность уже не та как в 2д, так что Кармак взял ближайшую альтернативу - Си
Не совсем, он использовал и ассемблер:
Вульф написан на C + x86-совместимый язык ассемблера
Дум 1-2 тоже на С + язык ассемблера
Первый квейк тоже С + язык ассемблера
И только с Квейк 2 начал писать на чистом С.
В смысле не сделал? Ultima Underworld вышла на 2 месяца раньше вульфа. Ох уж этот швитой кармак...
У которой игровая область в 1\4 от размера всей картинки и которая шла в 1-2 фпс? Ебать технологии. Кармак первый, кто сделал это нормально.
>Дебс, дум тоже шел в 1\4 на 1-2 фпс.
Что ты несешь, поехавший? Совсем на своей ненависти к кармаку кукухой поехал?
Сектант, поставь на реальное железо и посмотри. Там надо играть в милипиздрючном уменьшенном окошке, иначе 6 фпс.
Дебил, зачем ты пытаешься запустить игру 93 года на процессоре из 85? На 486 он точно идёт очень плавно. Да и чую ты пиздишь про 386, надо перепроверить
Потому что на таких и играли, свинопоридж. Когда DOOM был, были еще только 386-е и ниже, а 486 появились позже. Так что ничего и близко плавно не шло. Правно было только когда до максимума сжать окошко, но тогда толком ничего не видно. Приходилось играть на средне-уменьшенном окошке с умеренными тормозами.
Ну. Кхм.
Ну давай представим, что мы без объектов. Все статика.
Так вот. Смотри на прикриплейд 1. Все ок.
А теперь - на прикриплейд 2.
Как легко(как раз не очень легко) заметить, без ООП-срани и объектиков, вероятность на пустом месте выстрелить в ногу - уже на такой хуйне растет.
А теперь мы делаем с классами и прочей ООП-сранью(прикриплейд 3).
И чтобы работать с вот таким образом - мы обезопасили себя от того, что какой-то бака - передаст неверный невалидный хендлер, а у наз из-за этого все по пизде пойдет.
>Потому что на таких и играли, свинопоридж. Когда DOOM был, были еще только 386-е и ниже, а 486 появились позже.
Мудила, что ты несешь блядь?! 486 выпускались с 89 года, на момент выхода первого дума они продавались уже 4 года и были достаточно распространены.
>Так что ничего и близко плавно не шло. Правно было только когда до максимума сжать окошко, но тогда толком ничего не видно. Приходилось играть на средне-уменьшенном окошке с умеренными тормозами.
Дебич, если нет реального железа - поставь что-нибудь что эмулирует поведение реального 386 - PCem или досбокс с настройками под 386 на худой конец и посмотри своими глазами. Игра даже в полноэкранном режиме идет нормально. На глаз фпс явно больше 30 и даже при беге нет 6 фпс, как из твоего говноролика на ютубе.
>>2631893
А ты сам попробуй - я запустил и там фпс чуть ли не покадрово видишь как сменяется.
>У меня на i9-139000 30 фпc
>на глаз
>значит и на 386 было 30
Как пересать орать с дауна?
> 486 выпускались с 89 года, на момент выхода первого дума они продавались уже 4 года и были достаточно распространены
gtx1080ti выпускались с 2017 года, на данный момент они продавались уже 6 лет, однако распространена только gtx1060.
Свиновориджу не понять, что реальность и педовикия это разные вещи. Не говоря о распространенности, речь ведь идет про Россию, а до России компьютеры должны сначала дойти, а это не бывтро, и не было интернета, скачать игру в день выхода никак не получится, пока не привезут из америки дискеты и эти дискеты не разойдутся из рук в руки пол всей России никакого дуума ты не увидишь, свинопоридж, 90-е это не твои обоссаные зумерско-пидорские времена цифрогого погоса у каждого дебила в кармане, и заказов из америки онлайн с доставкой тебе в анус.
Малолетний долбоеб, хули ты порвался? Твои свинопориджи сейчас с тобой в одной комнате?
Там в другом проблема, почему-то базовый класс назван object, хотя должен быть class.
Малолетние свинопориджи думают гугл заменяет мозги и знания, типа загуглил и уже эксперд по любому вопросу, можно авторитетно кукарекать. Нет не заменяет, наоборот, только наглядно показывает тупых имбецилов гуглоботов.
Давай, долбоеб, покажи статистику распространенности 386 и 486 на момент 1993 года. Если у тебя ее нет - ты кукарекающий беспруфный петух.
>сам придумал поеботу, сам её опроверг
Молодец, шизофреник, разговаривай с собой перед зеркалом или в палате, а не публично. Это свинство, срать шизой публично. Просто нечистоплотность тупой свинины, которыя снимает штаны и срет прямо посреди тротуара где люди ходят. Думаешь, никто пизды не дает за такое в интернете, значит всё можно?
Дебила кусок, прекращай хрюкать. Пруфы твоих утверждений где?
Откуда ты вылез? Современные эмуляторы копируют поведение старого железа с идеальной точностью. Вот результат реального 386SX на 16 мегагерц и результат виртуальной ПК с 386SX. Результат в 21.21 одинаков с точностью до сотых.
Результат виртуальной видеокарты тоже совпадает с реальным.
Так что поведение софта в этих эмуляторах точно такое же как и на реальном железе.
Ну так это какой нибудь бенчмарк под который специально эмулятор затюнили. Ты игру на реальном запусти.
Тупее этого ничего придумать не мог? Затюнили специально под бенчмарк досовский - пиздец шиза. Ещё затюнили под сотню других бенчей - им же делать нехуй.
Чел, я сам делал поопкодовые эмули 8-битных процов, я знаю как там срезаются углы, тут мы делаем честную эмуляцию по байту, а тут не укладываемся и целиком пробрасываем вызов отрисовки на видеокарту целой картинки.
А, ну раз ты так делал, то и другие также делают! Там в настройках можно десятки моделей 286/386/486/пентиум1 выбирать и материнки под них. С каждой мамкой - свое поведение. Там даже если на виртуальный жёсткий диск не тот тип ide шины укажешь для матери - хуй чё определится, а если количество секторов и прочей хуерги правильно не укажешь - вообще пиздец.
Я кстати нихуя не понимаю почему ставишь процессор на 16 мегагерц, в досе он как 386sx-16 определяется но в тесте производительности частота 12,5 почему-то. И так на любой частоте. Хуй знает почему просадочка.