Por exemplo, espada e machado são duas classes diferentes, ambas herdadas da arma. Arma e poção também são classes diferentes, ambas herdadas do item.
Eu não faria as coisas dessa maneira; uma espada e um machado diferem principalmente em seus dados, não em seus comportamentos fundamentais como armas. Da mesma forma com os itens. Eu evitaria esse uso excessivo de herança, começando restringindo-se a justos Weapon
e Item
(você pode até dobrá-los em uma única classe, mas essa é uma discussão diferente). Se nada mais, isso aliviará a explosão de construtores em que você está vendo ItemWrapper
.
Portanto, ele deve ser um contêiner de ponteiros de itens (inteligentes). Como não quero escrever meu código com chamadas para new e delete, o agruparei em uma classe ItemWrapper que news / delete no ctor / dtor.
Considere os indicadores inteligentes Boost, em vez de usar os seus. Eles são bastante isolados do restante do Boost (para que você não tenha muitas dependências para usar se, por algum motivo, não quiser tirar proveito do restante das coisas legais do Boost), e muitos eles foram adotados para fazer parte da nova biblioteca padrão no C ++ 11, portanto, você não deve ter problemas para atualizar.
Esta é minha primeira tentativa, então gostaria de saber: estou indo no caminho certo? ou se existe uma maneira melhor de fazer isso (talvez uma que evite tantos construtores)?
Como acima, eu me esforçaria para evitar a herança para isso e consideraria o uso de soluções estabelecidas de terceiros em vez de criar as suas próprias. Somente essas etapas devem remover grande parte da complexidade da manutenção que você está descobrindo (ou descobrirá em breve).
Dito isso, outra abordagem é encará-la desta maneira: ItemWrapper
é um band-aid para um problema de detalhes de implementação. Ele próprio não representa um "objeto" real em nenhum sentido típico. Então pense no que poderia ser uma analogia melhor que também resolve seu problema de ter um lugar para colocar o automático new
e as delete
chamadas.
A maioria dos inventários permite que (alguns) itens sejam empilhados, não é?
A "capacidade de empilhamento" de um item é uma propriedade desse item, mas o item em si não deve ser responsável por manter a pilha. Se você tem uma classe representando ItemStack
métodos with para consultar o tamanho da pilha, dividir a pilha, etc., pode colocar seu gerenciamento da vida útil do ponteiro do item (que, devo observar, pode se tornar um pouco mais complicado com as pilhas , fornecendo assim outro argumento para usar algo como Boost) na classe stack junto com a implementação do restante de seu comportamento. Os itens que não podem ser empilhados são representados por uma pilha que sempre contém um único item, e seu próprio inventário ainda lida com instâncias homogêneas de ItemStack
.