История изменений

Это не альтернатива ООП, это просто не ООП пусть и с примесями. Зачем чему-то быть альтернативой ООП? ECS это ECS, ООП это ООП, Линукс это линукс, Виндовс это Винда. Они сами по себе, а не альтертативы. Конечно все пары/тройки/четвёрки и так далее имеют схожесть, имеют общие черты и применение у них одно даже, но CLI интерфейс не альтернатива GUI интерфейсу, вернее альтернатива, но только в том плане что это альтернативный вариант, а не альтернатива в смысле там всё также как было. Вещи можно делать просто по разному, вот и всё. Я не говорю что ООП по умолчанию ненужно, или айда все на ECS или ещё какую хрень. Нет, я просто против мании во всём видеть ООП и всё сводить к ООП, ого в ООП есть методы, а методы это функции значит всё у чего есть функции (процедуры!) это жалкое недоООП! И так ведь реально говорят. Что нравится, удобно и решает задачу то и используй, вот и всё. Ладно, я ещё сам себя поругаю, нравится всё называть ООП штырит кого от этого, да и похер пусть, но это рождает кучи недопонимания и глупых холиваров когда все говорят про одно, а подразумевают разное :D

Где тут альтернатива ООП?

Тут то что в ООП реализовать нельзя by desing. А именно возможность на лету менять логику работу программы, так как связность кода нулевая (ну почти, в реальности нет), вопросы реализации кишков ECS стоят особняком. Но суть в том что если уж смотреть на разницу то она проявится тогда когда ты упрёшься в то что для добавления фичи тебе нужно рефракорить код и всё что от него зависит, а тут ты можешь просто выключить/включить систему на лету и всё. У тебя дом и лошадь, дом стоит, лошадь умеет срать, сделай на ООП чтобы дом начал срать, в классическом ООП тебе нужно менять код дома, в ECS ты просто накинешь на дом компонент для срать в рантайме и нужная система которая уже есть сделает обосравшийся дом и это без измененения кодовой базы проекта вообще, если тебе такое не нужно то тебе не нужен ECS, если тебе такое нужно ты как дом обосрёшься с ООП =), но если ты с ECS будешь ну слишком гибкую систему делать то и тут обосрёшься ибо вариативность будет такой что ты в ней просто ориентироваться не сможешь. Всё имеет разумные границы, и под разумностью тут понимается то, какую сложность проекта разраб может держать у себя в голове, от того и разумность тут разная. Всё сводится к банальщине про которую уже говорил, тупо удобство, и некие побочки с которыми можно мирится и учитывать, но всё имеет предел.

Ещё раз, что удобно, что решает проблему то и используй, нет смысла говорить, а как XXX альтернативит YYY, они либо решают поставленные задачи, либо нет, уровень кактусожевания каждый для себя определяет сам.

А так, всё можно свести к процедурному программированию и оно решает абсолютно любые задачи, пусть я сейчас могу делать финты ушами на Lua такие что Lisp обзавидуется, но я рад что я когда то начал с сишки вижу что всё можно свести к процедурам, пусть порой без сахара, ну и ладно.

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

Цель сего описания такова. Мне пофигу, Бю :)

Это не альтернатива ООП, это просто не ООП пусть и с примесями. Зачем чему-то быть альтернативой ООП? ECS это ECS, ООП это ООП, Линукс это линукс, Виндовс это Винда. Они сами по себе, а не альтертативы. Конечно все пары/тройки/четвёрки и так далее имеют схожесть, имеют общие черты и применение у них одно даже, но CLI интерфейс не альтернатива GUI интерфейсу, вернее альтернатива, но только в том плане что это альтернативный вариант, а не альтернатива в смысле там всё также как было. Вещи можно делать просто по разному, вот и всё. Я не говорю что ООП по умолчанию ненужно, или айда все на ECS или ещё какую хрень. Нет, я просто против мании во всём видеть ООП и всё сводить к ООП, ого в ООП есть методы, а методы это функции значит всё у чего есть функции (процедуры!) это жалкое недоООП! И так ведь реально говорят. Что нравится, удобно и решает задачу то и используй, вот и всё. Ладно, я ещё сам себя поругаю, нравится всё называть ООП штырит кого от этого, да и похер пусть, но это рождает кучи недопонимания и глупых холиваров когда все говорят про одно, а подразумевают разное :D

Где тут альтернатива ООП?

Тут то что в ООП реализовать нельзя by desing. А именно возможность на лету менять логику работу программы, так как связность кода нулевая (ну почти, в реальности нет), вопросы реализации кишков ECS стоят особняком. Но суть в том что если уж смотреть на разницу то она проявится тогда когда ты упрёшься в то что для добавления фичи тебе нужно рефракорить код и всё что от него зависит, а тут ты можешь просто выключить/включить систему на лету и всё. У тебя дом и лошадь, дом стоит, лошадь умеет срать, сделай на ООП чтобы дом начал срать, в классическом ООП тебе нужно менять код дома, в ECS ты просто накинешь на дом компонент для срать в рантайме и нужная система которая уже есть сделает обосравшийся дом и это без измененения кодовой базы проекта вообще, если тебе такое не нужно то тебе не нужен ECS, если тебе такое нужно ты как дом обосрёшься с ООП =), но если ты с ECS будешь ну слишком гибкую систему делать то и тут обосрёшься ибо вариативность будет такой что ты в ней просто ориентироваться не сможешь. Всё имеет разумные границы, и под разумностью тут понимается то, какую сложность проекта разраб может держать у себя в голове, от того и разумность тут разная. Всё сводится к банальщине про которую уже говорил, тупо удобство, и некие побочки с которыми можно мирится и учитывать, но всё имеет предел.

Ещё раз, что удобно, что решает проблему то и используй, нет смысла говорить, а как XXX альтернативит YYY, они либо решают поставленные задачи, либо нет, уровень кактусожевания каждый для себя определяет сам.

А так, всё можно свести к процедурному программированию и оно решает абсолютно любые задачи, пусть я сейчас могу делать финты ушами на Lua такие что Lisp обзавидуется, но я рад что я когда то начал с сишки вижу что всё можно свести к процедурам, пусть порой без сахара, ну и ладно.

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

Бю :)