To ensure consistency, IGraphicManager should not provide public routines to add an object with the iGraphic interface. Instead, it may provide public factory methods where clients request new instances of IGraphic, and those instances would become "automatically" member of the particular m_graphics[] field before the factory returns.

...
Actually I currently have a GraphicsFactory for creating instances of IGraphic implementations. The problem is that if the IGraphic instance gets added to the GraphicsManagers array only by the factory it will only get drawn once. That is because I wanted to empty the array everytime it drew every IGraphic on the screen (as described above).

Sorry, I haven't noticed that m_graphics[] is for storing rendering jobs. I should have read your OP more carefully. Perhaps the overused term "manager" has confused me

Nevertheless, the principle still holds. Any collection of IGraphic that hold all instances of IGraphic is a kind of scene description (e.g. an array m_allGraphics[]). If IGraphicManager provides a factory for suited IGraphic instances and the allGraphics collection, and further does not publicly allow to add IGraphic instances to that collection, then type consistency (in this sense of Hodgman's comment) is given. For sure, you have to ensure something similar for any collection.

Not offending, but ... that brings up the question whether the overall design is that clear at all. I mean IGraphic is AFAIS a renderable, a renderer (because of draw()), has an own resource management (hinted at by the loadGraphic routine), represents a render job. What happens when sound comes into play? Of course, I have no deep insight into your design just from those one or two diagrams, but I personally have the impression it is the way you go, and I would ever try to avoid such an aggregation of different functionality. IMHO your design massively violates the "single responsibility principle".

Usually concepts like shared resources (requiring a central resource management), outsourced batch processing (often needed when dealing with sprites and similar masses of renderable objects; we're speaking of a 2D project here, right?), exchangeable graphic APIs (and other sub-systems), aspect oriented management of game objects (I mean dropping the omnipotent scene graph approach), pluggable game objects (to avoid the accumulation of from case-to-case mostly superfluous functionality in base classes) ... all lead to "degrading" a renderable to just that: A description of graphical rendering, but not more.

Just my 2 EUR-Cent.