- There are "attack" objects, which all inherit from a base attack class (and may be composed of some other things in the future)—they do all the calculations given a character's stats and some damage multiplier. This will make it easier to give specific characters specific abilities. When performing an attack, one of these objects is created, passed to an attack-event, and an attack-handler applies all the appropriate damage.
Sounds reasonable -- just beware the urge to derive a new object for each kind of attack. As a rule of thumb, strive to keep the number (and especially the depth) of derivations small. The basic approach in this case would be to only make a new kind of attack object when the attack formula is different -- by this I mean the actual shape of the formula, not just having different constant factors ("weights" or "multipliers") -- those can be passed into the constructor of the Attack.
- Items have the same attribute-map as characters. When items are equipped, an iterator just adds the appropriate item stats to the character stats by key (equipping, picking up items, etc. is actually handled by a handler, too, since it requires things like removing an item from a room and putting it in the character's inventory.)
Again, the idea is reasonable. There are a couple ways to approach this that immediately jump to mind. If most equipment/status-effects effect only one stat, then it might be better to have a list of such things (e.g. built up by looking at currently-equiped items and active status effects) and playing their effect on a copy of the player status object. This is fairly simple (its something like the Command Pattern). If many equipable items/status-effects effect multiple stats, then it might be better to have a list of 'filters' which derive from the stat object and "wrap" another stat object (the player stats at the root, or another stat filter) to present a filtered view -- in that way they can be chained together to apply stacking status modifiers (its something like the Decorator Pattern). In either case, an attacker might be allowed to have their own modifiers (say, a certain enemy type removes or reduces magic resistance, even that due to equipped items).
I still say that a map of strings-to-integers is both overkill (provides dynamism of stat names and number of stats you're not using and don't seem to need), and too limiting (all stats can only be integers), but you might have reasons that aren't clear, or might just be more comfortable with what you have. If it were me, I'd have a struct/class representing stats (or stat-packs, if different entity types or characters might have different sets of stats). You might be aiming for the flexibility to add unknown stats at a later time, but unless you want to be able to invent new stats at runtime (e.g. your 'game' itself is just configuration/data) the unused flexibility probably imposes more headache than you gain back in utility.