Удобное хранение Item в инвентаре игроков, домов и автомобилей

[DeimoS]

Меня просто очень смущает и никак не даёт успокоится тот факт, что все эти три системы будут однотипны и надо делать 3 разные системы.

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

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

UPD: Ну если прямо очень свербит вся эта ситуация, то, для начала, скинь хотя бы примеры кода или опиши более подробно те моменты, которые тебе не нравятся. Ибо описание "системы будут однотипные" не говорит ни о чём, так как даже инвентарь можно множеством разных способов реализовать.

[execution]

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

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

UPD: Ну если прямо очень свербит вся эта ситуация, то, для начала, скинь хотя бы примеры кода или опиши более подробно те моменты, которые тебе не нравятся. Ибо описание "системы будут однотипные" не говорит ни о чём, так как даже инвентарь можно множеством разных способов реализовать.

Да, ты прав. Также обнумав на досуге понял, что разделение самое оптимальное для правок, спасибо.

[punkochel]

Почему бы не сделать, скажем переменную Place, создать константы INV_PLACE_HOUSE, INV_PLACE_CAR... которая будет отвечать за место в котором хранится предмет?

[DeimoS]

Почему бы не сделать, скажем переменную Place, создать константы INV_PLACE_HOUSE, INV_PLACE_CAR... которая будет отвечать за место в котором хранится предмет?

А зачем вообще указывать место, в котором хранится предмет, если об этом и так будет говорить то, в каком массиве хранятся данные?

[punkochel]

А зачем вообще указывать место, в котором хранится предмет, если об этом и так будет говорить то, в каком массиве хранятся данные?

Так это именно на тот случай, если человек хочет сделать один массив для всевозможных предметов.

[DeimoS]

Так это именно на тот случай, если человек хочет сделать один массив для всевозможных предметов.

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

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