Тёмная тема
- kkolyan
- Участник
=A=L=X=
окей, допустим, есть два значения термина ООП
A. некая идея, когда-то кем-то выдвинутая, повлиявшая на дальнейшее развитие ЯП, преобразовавшись в те или иные формы.
Б. конкретный подход, реализованная во многих современных языках (и в некоторых несовременных) и популяризованный их учебниками:
но что имеет ввиду под ООП среднестатистический программист с gamedev.ru или из окологеймдев чатов? По моему опыту - "Б".
(так-то да, на мой взгляд, и ECS как подход обладает чертами ООП, но со мной мало кто соглашался)
=A=L=X=
> можно написать код который не знает с объектом какого именно типа в рантайме работает - всё, это ООП
по твоему, полиморфизм - достаточный критерий ООП? грубо.
объявляю на гейдеве неделю ООП bikeshedding'а — обсуждения по теме, в которой каждый может найти, что сказать, потому что всё равно нельзя прийти ни к какому внятному заключению.
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 выглядит как более чем удовлетворяющий этим лекалам.
kkolyan
>
> (так-то да, на мой взгляд, и ECS как подход обладает чертами ООП, но со мной
> мало кто соглашался)
Потому что он как раз не обладает. Основа ООП это взаимодействия разных модулей с помощью сообщений, а не через данные. В ECS же ты взаимодействуешь с данными
=A=L=X=
твоя интерпретация ООП мне прям по душе) но мне кажется, очень уж многие ей не следуют, что затрудняет использование термина в таком широком смысле.
=A=L=X=
> А наследование как в мейнстриме - это не более чем клей как заставить статически типизированный язык работать с объектами неизвестных заранее типов.
разве? наследование от интерфейсов - да. такое есть и в Go (кря) и в Rust. в терминологии явы, раста и го - это и не наследование вовсе.
а наследование, которое именно наследование - в большей степени инструмент реюза путем композиции новых классов из базовых. и очень для многих это чуть ли не основной кит ООП.
FlyOfFly
> Потому что он как раз не обладает.
ага, а выше ты утверждал что без ООП невозможно реализовать ECS фреймворк. ты даже не пытаешься искать инфу, а выдаешь догадки за факты, ожидая что оппонент проведет тебе ликбез, после которого ты в лучшем случае не раскидаешь фигуры на столе и не улетишь. сорян, мне не интересен такой формат общения.
kkolyan
> ага, а выше ты утверждал что без ООП невозможно реализовать ECS фреймворк
и как это противоречит моим словам?
kkolyan
> ты даже не пытаешься искать инфу,
???Странно и обидно слышать это от человека, который называет ECS - ООП, хотя он максимально им и не является и если посмотреть историю ООП, а вернее smalltalk это становится очевидным
kkolyan
> по твоему, полиморфизм - достаточный критерий ООП? грубо.
Ни в коем случае!
Чтобы язык считался оопшным, он должен обладать следующими фичами
1) переменные можно объединять в структуры.
2) наследосание полей и функций
3) инкапсуляция
4) полиморфизм
5) возможность кастовать указатель вверх, вниз, вбок
kkolyan
> ECS
Это не ооп. Это отдельный способ программирования, совместимый с другими.
Например так
using MyComp=uniquie_ptr<MyInterface>;
samrrr
> Это не ооп
да что ты. а кто сказал что ECS это ООП?
samrrr
> Например так
я совсем не об этом
kkolyan
> ECS как подход обладает чертами ООП
Тыж это написал.
У ECS с ООП схоже только то, что они оперируют объектами, всё остальное различное.
samrrr
> ECS это ООП
> ECS как подход обладает чертами ООП
не понимаю, как ты вообще программируешь, если не видишь существенную разницу между этими формулировками.
PS: а, кажется понял. у тебя в крестах же "наделение чертами" делается чреез множественное наследование. а наследование является реализацией отношения "является". вот все и смешалось.
в ECS же нет полиморфизма. Так что по алексовскому он как раз не ООП.
там вместо foreach element {element.process} делают foreach picture process_picture(picture), foreach element with size (process_sized(element)).
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 кроме того, что у него есть здоровье. чем не полиморфизм?
kkolyan
ну так regensystem и обрабатывает только компонент здоровья. Нет никакого разного поведения в зависимости от типа переданной энтити. Ну т.е. с точки зрения бизнес-логики - да, это можно считать полиморфизмом, но с точки зрения кода - наоборот, нет ни свитчей ни виртуальных таблиц, весь код работает строго с конкретными данными.