The gem of the article was the articulation of "an object's type is the union of its class and properties". That's how it is, I just hadn't seen it in writing b

The gem of the article was the articulation of "an object's type is the union of its class and properties". That's how it is, I just hadn't seen it in writing before. It also strikes a chord with what I felt bad about in his examples: nothing really helps if your game has 150 monster classes. You could attack from the outside by putting the method in Elf class and overloading by the parameters: public boolean doesElfLikeIt ( Elf mon ) { ... } public boolean doesElfLikeIt ( Orc mon ) { ... } public boolean doesElfLikeIt ( Monster mon ) { ... } // default if your language can do that. Otherwise you'll have to do it manually, i.e. threatening little children with switch statements. But classes are amorphic, it's like trying to reshape glass that's once burned. Having a single Monster class and codifying its type mostly in its properties (which themselves may be instances of other classes) seems like a much better way.