This looks crazy to me (but is it? I'm trying to learn something here and my assumptions or thinking pattern might be completely wrong), the creature should have it's properties inside it. Some properties can be abstracted in there own classes if that makes common sense but one can still end up with an object that has many properties. If we do what Yegor suggests we do, making all these properties final then we inevitably end up with large constructors or a builder pattern with a large amount of mandatory properties.Map<Integer, Creature> CreatureMap = new HashMap<Integer, Creature>(); Map<Integer, Stats> statsMap = new HashMap<Integer, Stats>(); Map<Integer, Equipment> equipmentMap = new HashMap<Integer, Equipment>(); public void createCreature() { int index = getNextIndex(); creatureMap.put(index, new Creature()) statsMap.put(index, new Stats()); equipmentMap.put(index, new Equipment); } public void mutateCreature(int index) { creatureMap.put(index, creatureMap.get(index).mutateSomething()); }
This looks to me like an entity-component system. We've been getting lots of questions about those recently. There are some advantages to this kind of approach as long as you don't follow it too dogmatically. In particular, it lets you not bother creating the components that don't need to exist for an object - do trees really need pathfinding, for example? Does a player character really need an AI state? What about creatures that can't (by design) carry equipment? Though, this particular point applies to composition generally.
I'd hardly call it crazy. My own side projects follow this sort of architecture because it makes it easier to add new features and because it allows me to use existence-based processing on the resulting components. In a lot of cases (not all) this makes the resulting code simpler.