There's a principled way to exclude many bad designs for this type of problem: constraining the classes to be reasonable ones.
-
Character and Weapon are different enough to be two different acceptable classes, but...
-
Subclasses of Character and Weapon shall not exist, because the differences between them are trivial and ill-defined.
-
Formal representations of weapon and character "types" could be objects, enum values, constants or the like. Not classes, because there's only one class.
-
Also allowed: CharacterClass and WeaponType, shared by many Character or Weapon individuals either as a factory or template providing a default initial state or as a live read-only prototype.
This rules out bullshit inheritance hierarchies (all are bad!) and suggests, instead, giving every Character and every Weapon a set of tags and checking whether the tags are compatible. It could be done in two ways.
-
Simplified and ad-hoc: the set of tags is the same for characters and weapons (wizards and staves are tagged "easy", warriors and swords are tagged "cutting or piercing") and weapons can be used if character tags intersect weapon tags (allowing e.g. traditional D&D weapon restrictions: clerics, staves, maces and clubs tagged "blunt", warriors tagged "blunt" in order to use any weapon, daggers tagged both "easy" and "cutting or piercing"). Every system is likely to need separate and somewhat redundant tags.
-
Rule-based: tags describe the character or weapon freely ("weapon incompetence" for wizards, "vow not to draw blood" for clerics, "military training" for warriors) and an explicit rule table connects character and weapon tags. There would be some hope to reuse the tags for different purposes (e.g. character skills or weapon maintenance), but rules would be fairly complex.
