you rewrote it, so no, not what I was trying to show you.
What I was saying is the the version of character above my previous post... reusing that in a new game that doesn't have any kind of healing...
Its not hard to do, just highlights the baggage that comes with the design a little: your new code has to do something about the function it doesn't need and you have to know a lot more about the class you are using than a user normally needs (implementation details)... then imagine you didn't write the original but were getting something from elsewhere to reuse and had to know those kinds of details.. Nothing insurmountable, just things to think about.
Ah, so i think i understand, so i should break up the components more, so maybe i could have a Health class and a Magicka Class and then if i want to make similar characters i can, and if i dont want them having regenerating health then i can easily change that by writing my own little health class thats custom for my game. Then i can use composition to define a Has-A relationship between them (Character Has Health, Character Has Magicka). Is that more what you meant?
I just wanted you to think about it. Breaking things into smaller bits is one way to do it, you could also consider whether your objects really needed the polymorphic capability, or if something like a callback may be the way to get there, or whatever. At this point we are retrofitting a design onto code that was really an example and a case study, so trying to 'fix' it from here isn't the point at all. The point was just for you to consider how you might paint yourself into a corner with this tool, so you are aware of it when you decide to use it. Its not like where I said try not to use it (with pointers, way back) ... you want to use this tool.