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

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

А так, используй всё подряд там где это к месту, удобно и разумно и всё.

Как применять инструменты правильно?

Никак, не существует никакого «правильно», правильно так как ты решишь, не бойся принимать решения, не стремись слепо следовать чему-то просто потому что сам боишься сделать что-то не так. Один фиг будет что-то не так, но ты это поймёшь на практике увидев эффекты от решений и применишь иной подход, целиком для проекта или частично для его куска.

Где находится та грань, когда нужно использовать ООП

Для ООП в вакууме нигде она не находится. Тебе удобен подход? У тебя нет необходимости постоянно менять код добавляя фичи и из за этого рефракторить всё что с ним связано после изменений, используй. Видишь проблему связанную с подходом в конкретном случае (буквально модет одном файле) не используй, вот и всё.

что под ООП в данном случае подразумеваю то самое махровое ООП из пропаганды маркетологов

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

Итого, ООП изначально был создан как помощ людям, мысленная абстракция представления кода выражающего состояния и поведения объектов, так просто удобнее мыслить, для этого сделали синтаксические сахара, переименовали функции в интерфейсы, а структуры в классы, добавили логическое разделение публичного кода и приватного, ну руки наружу, а кишки внутри, добавили сахар для расширения возможностей через простой как палка механизм наследования, и всё, всем было просто и понятно. Причём частично или полностью эта (я продолжу утверждать) просто солянка реализуемая на чём угодно, если так хочется. Но потом пришли те самые шизики и начали из простой концепции что-то сверху нахлобучивать, закладывать туда какие то смыслы, правила, причём строгие, какую-то идеологию правильного ООП выдумали, истинное ООП, ложное ООП и прочий бред сивой кобылы, и на серьёзных щах рассказывают что не ООП было создано из кусочков разных подходов, а это ООП породило что-то, и если я в структуру положил указатель на функцию это я типа пытаюсь сделать жалкую пародию на интерфейс ООП через костыли передачи самой структуры в в хранимую в ней функцию, вот от этого вообще лицо рука.

Иными словами, используй что тебе удобно, всё вот это «правильное» оставь маркетологам. Правильно, это то что правильно для конкретно твоего проекта в реализации конкретной проектной подзадачи. Никакой в мире подход к разработке не является правильным, несколько лет назад за слова о javascript на высоконагруженном бекенде все бы смеялись, надрывая животики и пукая показывай пальцем на дурачка который про это сказал, а сейчас кхм и там появились свои Ынтырпрайз решения, «правильное» программирование, искусственное накручивание серьёзности и прочее прочее.

Когда дело касается конкретных задач да, любая применяемая технология включая язык будет рассматриваться серьёзно, будут поиски оптимальных решений причём не только технических, а ещё социальных, как учить людей, чему учить и так далее, может завтра на полном серьёзе будут на brainfuck клиент-сервер писать и там тоже будет всё серьёзно.

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

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

Итого, если говорить про игры, то часть проекта у тебя может быть в стиле ООП, чёткая выверена, интерфейсы стабильное API и прочее. А часть чисто процедурная, а часть ещё какая. И норм, все так и делают.

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

Так как же поступать?

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

Дочитал? Во ты псих! Делать тебе больше нечего!

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

А так, используй всё подряд там где это к месту, удобно и разумно и всё.

Как применять инструменты правильно?

Никак, не существует никакого «правильно», правильно так как ты решишь, не бойся принимать решения, не стремись слепо следовать чему-то просто потому что сам боишься сделать что-то не так. Один фиг будет что-то не так, но ты это поймёшь на практике увидев эффекты от решений и применишь иной пордход, целиком для проекта или частично для его куска.

Где находится та грань, когда нужно использовать ООП

Для ООП в вакууме нигде она не находится. Тебе удобен подход? У тебя нет необходимости постоянно менять код добавляя фичи и из за этого рефракторить всё что с ним связано после изменений, используй. Видишь проблему связанную с подходом в конкретном случае (буквально модет одном файле) не используй, вот и всё.

что под ООП в данном случае подразумеваю то самое махровое ООП из пропаганды маркетолухов

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

Итого, ООП изначально был создан как помощ людям, мысленная абстракция представления кода выражающего состояния и поведения объектов, так просто удобнее мыслить, для этого сделали синтаксические сахара, переименовали функции в интерфейсы, а структруты в классы, добавили логическое разделение публичного кода и приватного, ну руки наружу, а кишки внутри, добавили сахар для расширения возможностей через простой как палка механизм наследования, и всё, всем было просто и понятно. Причём частично или полностью эта (я продолжу утверждать) просто солянка реализуемая на чём угодно, если так хочется. Но потом пришли те самые шизики и начали из простой концепции что-то сверху нахлобучивать, закладывать туда какие то смыслы, правила, причём строгие, какую-то идеологию правильного ООП выдумали, истинное ООП, ложное ООП и прочий бред сивой кобылы, и на серьёзных щах рассказывают что не ООП было создано из кусочков разных подходов, а это ООП породило что-то, и если я в структуру положил указатель на функцию это я типа пытаюсь сделать жалкую породию на интерфейс ООП через костыли передачи самой структуры в в хранимую в ней функцию, вот от этого вообще лицо рука.

Иными словами, используй что тебе удобно, всё вот это «правильное» оставь маркетологам. Правильно, это то что правильно для конкретно твоего проекта в реализации конкретной проектной подзадачи. Никакой в мире подход к разработке не является правильным, несколько лет назад за слова о javascript на высоконагруженном бекенде все бы смеялись, надрывая животики и пукая показывай пальцем на дурачка который про это сказал, а сейчас кхм и там появились свои Ынтырпрайз решения, «правильное» программирование, искусственное накручивание серьёзности и прочее прочее.

Когда дело касается конкретных задач да, любая применяемая технология включая язык будет рассматриваться серьёзно, будут поиски оптимальных решений причём не только технических, а ещё социальных, как учить людей, чему учить и так далее, может завтра на полном серьёзе будут на brainfuck клиент-сервер писать и там тоже будет всё серьёзно.

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

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

Итого, если говорить про игры, то часть проекта у тебя может быть в стиле ООП, чёткая выверенна, интерфейсы стабильное API и прочее. А часть чисто процедурная, а часть ещё какая. И норм, все так и делают.

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

Так как же поступать?

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

Дочитал? Во ты псих! Делать тебе больше нечего!