This is posted in 2007 but it is still useful, at least a possible solution.
As of right now, I am still doing game entities like he is describing except it is divided up into three parts which are events, models, and controllers. It was largely the result of having the needs to easily doing unit test without doing extremely complicated of a setup and as well making it far easier to maintain my code.
This setup migrates the game codebase from total disaster to something that is much cleaner. Now that this article has come into views, I fear that the codebase I have will slip back into oblivion as models, their corresponding rendering code, and the controllers gathers into blobs.
Having been through this sort of headache a couple of times, I'm convinced that the coupling of functionality must be as loose as possible. It sounds like OP's solution follows that approach, although he's a bit thin on specifics. Another useful concept in this context that is usually unknown (and often partially reinvented) by C++ programmers is protoypal inheritance. C++ makes this anything but simple, and you essentially have to reinvent your object system. It can be done, but it's not pleasant. I'll need to try these things in more expressive languages sometime.
As of right now, I am still doing game entities like he is describing except it is divided up into three parts which are events, models, and controllers. It was largely the result of having the needs to easily doing unit test without doing extremely complicated of a setup and as well making it far easier to maintain my code.
This setup migrates the game codebase from total disaster to something that is much cleaner. Now that this article has come into views, I fear that the codebase I have will slip back into oblivion as models, their corresponding rendering code, and the controllers gathers into blobs.