Войти
ФлеймФорумПрограммирование

Общие вопросы по программированию (509 стр)

Страницы: 1508 509 510 511559 Следующая »
#7620
(Правка: 12:55) 12:54, 4 окт 2022

=A=L=X=
окей, допустим, есть два значения термина ООП

A. некая идея, когда-то кем-то выдвинутая, повлиявшая на дальнейшее развитие ЯП, преобразовавшись в те или иные формы.

Б. конкретный подход, реализованная во многих современных языках (и в некоторых несовременных) и популяризованный их учебниками:

+ Показать

но что имеет ввиду под ООП среднестатистический программист с gamedev.ru или из окологеймдев чатов? По моему опыту - "Б".
(так-то да, на мой взгляд, и ECS как подход обладает чертами ООП, но со мной мало кто соглашался)

=A=L=X=
> можно написать код который не знает с объектом какого именно типа в рантайме работает - всё, это ООП
по твоему, полиморфизм - достаточный критерий ООП? грубо.

#7621
13:02, 4 окт 2022

объявляю на гейдеве неделю ООП bikeshedding'а — обсуждения по теме, в которой каждый может найти, что сказать, потому что всё равно нельзя прийти ни к какому внятному заключению.

#7622
(Правка: 13:22) 13:08, 4 окт 2022

kkolyan
> по твоему, полиморфизм - достаточный критерий ООП? грубо.

Да, верно, но не грубо, а в точку.
Если совсем вкратце, то до ООП редактор допустим текста с картинками хранил бы список из неких структур в которых было грубо говоря было бы поле type - параграф это текста или картинка и все процедуры обрабатывающие switch type в мешанину кода где сплетался бы код разных сущностей от определения высоты фрагмента документа до сохранения на диск - везде была бы корявая идиома foreach element: case element.type.
ООП-нутый подход просто сказал - хватит это терпеть, пусть каждый element сам знает как ему считать свою высоту или сохраняться в файл и все эти паттерны заменились на foreach element: element.doSomething, и в итоге при добавлении нового элемента, например, видеоролика, весь уже написанный код про высоту или сохранение в файл продолжает работать, остаётся только прилинковать к проекту новый модуль с сущностью видеоролика.
Поэтому в процедурном подходе каждая процедура всегда знала какой тип объекта в неё попадает или была ограничена по такому набору изначально (switch type).
В ООП-нутом же подходе процедуры могут не знать какой тип объекта в них попадает и несмотря на это работать с объектами которые были написаны позднее нежели эта процедура.
Это главная разница.
А наследование как в мейнстриме - это не более чем клей как заставить статически типизированный язык работать с объектами неизвестных заранее типов. Но это далеко не единственный механизм как это можно сделать. В языках по типу C++ element.doSomething превращается в полиморфный динамический поиск функции через таблицу виртуальных методов гарантированно совместимую с нужной нам путём дерева наследования.
А например в скриптовом языке element.doSomething может превращаться в поиск в element поля doSomething с попыткой вызвать его как функцию куда element отправится первым параметром - всё тоже в динамике и только это тут и требуется без всяких наследований. Утиная типизация, ква-кря.
И Go выглядит как более чем удовлетворяющий этим лекалам.

#7623
13:48, 4 окт 2022

kkolyan
>
> (так-то да, на мой взгляд, и ECS как подход обладает чертами ООП, но со мной
> мало кто соглашался)
Потому что он как раз не обладает. Основа ООП это взаимодействия разных модулей с помощью сообщений, а не через данные. В ECS же ты взаимодействуешь с данными

#7624
(Правка: 14:15) 14:12, 4 окт 2022

=A=L=X=
твоя интерпретация ООП мне прям по душе) но мне кажется, очень уж многие ей не следуют, что затрудняет использование термина в таком широком смысле.

=A=L=X=
> А наследование как в мейнстриме - это не более чем клей как заставить статически типизированный язык работать с объектами неизвестных заранее типов.
разве? наследование от интерфейсов - да.  такое есть и в Go (кря) и в Rust. в терминологии явы, раста и го - это и не наследование вовсе.

а наследование, которое именно наследование - в большей степени инструмент реюза путем композиции новых классов из базовых. и очень для многих это чуть ли не основной кит ООП.

FlyOfFly
> Потому что он как раз не обладает.
ага, а выше ты утверждал что без ООП невозможно реализовать ECS фреймворк. ты даже не пытаешься искать инфу, а выдаешь догадки за факты, ожидая что оппонент проведет тебе ликбез, после которого ты в лучшем случае не раскидаешь фигуры на столе и не улетишь. сорян, мне не интересен такой формат общения.

#7625
14:16, 4 окт 2022

kkolyan
> ага, а выше ты утверждал что без ООП невозможно реализовать ECS фреймворк
и как это противоречит моим словам?
kkolyan
> ты даже не пытаешься искать инфу,
???Странно и обидно слышать это от человека, который называет ECS - ООП, хотя он максимально им и не является и если посмотреть историю ООП, а вернее smalltalk это становится очевидным

#7626
14:18, 4 окт 2022

kkolyan
> по твоему, полиморфизм - достаточный критерий ООП? грубо.
Ни в коем случае!

Чтобы язык считался оопшным, он должен обладать следующими фичами
1) переменные можно объединять в структуры.
2) наследосание полей и функций
3) инкапсуляция
4) полиморфизм
5) возможность кастовать указатель вверх, вниз, вбок

#7627
14:24, 4 окт 2022

kkolyan
> ECS
Это не ооп. Это отдельный способ программирования, совместимый с другими.
Например так

using MyComp=uniquie_ptr<MyInterface>;
#7628
14:27, 4 окт 2022

samrrr
> Это не ооп
да что ты. а кто сказал что ECS это ООП?

samrrr
> Например так
я совсем не об этом

#7629
14:28, 4 окт 2022

kkolyan
> ECS как подход обладает чертами ООП
Тыж это написал.

#7630
14:30, 4 окт 2022

У ECS с ООП схоже только то, что они оперируют объектами, всё остальное различное.

#7631
(Правка: 15:16) 15:01, 4 окт 2022

samrrr
> ECS это ООП
> ECS как подход обладает чертами ООП
не понимаю, как ты вообще программируешь, если не видишь существенную разницу между этими формулировками.

PS: а, кажется понял. у тебя в крестах же "наделение чертами" делается чреез множественное наследование. а наследование является реализацией отношения "является". вот все и смешалось.

#7632
15:19, 4 окт 2022

в ECS же нет полиморфизма. Так что по алексовскому он как раз не ООП.
там вместо foreach element {element.process} делают foreach picture process_picture(picture), foreach element with size (process_sized(element)).

#7633
16:12, 4 окт 2022

kipar

var turret = world.NewEntity().AddComponent(new Health()).AddComponent(new SomeTurretComponent());
var soldier = world.NewEntity().AddComponent(new Health()).AddComponent(new SomeSoldierComponent());

void RegenSystem() {
  foreach (EntityView<Health> entity: world.Query<Health>()) {
    entity.Get1().value += 10;
  }
}

RegenSystem ничего не знает о том, что кроется за entity кроме того, что у него есть здоровье. чем не полиморфизм?

#7634
(Правка: 16:29) 16:28, 4 окт 2022

kkolyan
ну так regensystem и обрабатывает только компонент здоровья. Нет никакого разного поведения в зависимости от типа переданной энтити. Ну т.е. с точки зрения бизнес-логики - да, это можно считать полиморфизмом, но с точки зрения кода - наоборот, нет ни свитчей ни виртуальных таблиц, весь код работает строго с конкретными данными.

Страницы: 1508 509 510 511559 Следующая »
ФлеймФорумПрограммирование