Interfaces are good so long as they're abstract. Once you start getting to where you can specify data or functions, then you should start using real classes. Like for the IMovable. That is at least something with a location, so right there it has some specific data and functions for that data. (Actually you might as well let the location data be public if it's simple enough.) IControlCommand might not be an interface either.
I'm not sure what you're thinking of with the IObjectState for the IUpdatable. My purpose of the IUpdatable is that it has an update function. This way you can have a collection of IUpdatables to loop through in the update task, just like you'd have a collection of IRenderable to call Render on in the render task. States for objects probably wouldn't be needed till you get to something more specific.
And for resources, I have to think a bit about how resource management would work.
__________________
<div style="float: right; width: 100px; height: 70px; margin: 5px 15px;"><img src="http://madskills.org/monolith/idleserver.gif" style="width: 98px; height: 65px;"><img src="http://madskills.org/monolith/theserver.gif" style="width: 98px; height: 65px; position: relative; top: -65px;"></div><div style="margin: 0 3em; font-size: 80%; font-style: italic;">Love is patient, love is kind. It does not envy, it does not boast, it is not proud. It is not rude, it is not self-seeking, it is not easily angered, it keeps no record of wrongs. Love does not delight in evil but rejoices with the truth. It always protects, always trusts, always hopes, always perseveres.</div><div style="text-align: right; text-size: 80%;">1 Corinthians 13:4-7</div>
|