Предложение шаблона проектирования для использования предметов из инвентаря

Это классический случай, когда в игру вступают интерфейсы, наследование и полиморфизм. Всякий раз, когда вы используете switch или последовательность if, вы должны учитывать полиморфизм.

В этом случае определите интерфейс или абстрактный класс для используемого элемента.

public interface Useable {
   public void useItem(Person personUsing);
}

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

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

public interface ItemInterface { 
    public String getName();
    public String[] getCharacteristics(); 
}

Я бы определил некоторые эффекты предметов, обрабатывающие логику:

public interface ItemEffectInterface {
    public String getName();
    public void affectCharacter(ItemInterface item, CharacterInterface character, parameters);
    public void affectInventory(ItemInterface item, InventoryInterface inventory, parameters);
    public void affectGame(ItemInterface item, GameInterface game, parameters); 
}

Я использую интерфейсы для всех своих объектов, чтобы создать слабую связь между моими классами (это обеспечивает более масштабируемый, поддерживаемый и тестируемый код).

Вы можете определить абстрактный класс AbstractItemEffect, если хотите определить поведение по умолчанию «ничего не делать» в эффектах вашего элемента-расширителя для всех методов и просто определить активные методы для каждого эффекта.

Затем, если вам нужна динамичная настраиваемая игра, вы можете определить взаимодействие предмета и эффектов в файле/базе данных. Вот пример JSON:

[
    {
        "item": "health potion",
        "effect": "heal",
        "parameters": {
            "hp": 100
        }
    },
    {
        "item": "mana potion",
        "effect": "regen",
        "parameters": {
            "mp": 150
        }
    },
    {
        "item": "mana potion",
        "effect": "drunk",
        "parameters": {
            "duration": 1000
        }
    },
    ...
[

Затем используйте класс обслуживания, чтобы сопоставить эффект с элементами при использовании:

public class ItemUser {
    private Map itemEffects = new HashMap();

    // Call it at service initialization after interpreting the configuration
    // (configuration is optional, you can call it directly of course).
    public void addItemEffect(ItemInterface item, ItemEffectInterface itemEffect, parameters) {
        Map effect = new HashMap();
        effect.push("effect", itemEffect);
        effect.pust("parameters", parameters);

        this.itemEffects.put(item.getName(), effect);
    }

    // Call it when you want to use an item.
    public void useItem(ItemInterface item, Character character, GameInterface game, InventoryInterface inventory) {
        Map itemEffects = this.itemEffect[item.getName()];

        // Process all the effects attached to your item 
        // on game, character, inventory, ...
    }
}

С помощью этой архитектуры вы можете прикрепить эффект ко многим элементам и элемент ко многим эффектам. Это должно предотвратить дублирование кода.

В то же время каждый предмет и эффект предмета будут иметь собственную сложность и не усложнят всю систему. Это не относится к шаблону «переключение регистра», подобному тому, который вы описываете в 2.. Представьте свой класс, если у вас есть 100 эффектов и 200 предметов...

Извините за мой плохой/неполный код JAVA!