Use one core entity for all game screens.
Overall, though, your issue is one of decoupling the correct classes in the correct places.
Method 1: Per-Entity renderer class, separate from core Entity controller
Here you have a different IEntityView
(let's call it) component per screen AND per entity, so if you had two game screens and 100 entities, you'd have a total of 200 entity view components. Each of these would reference a core Entity model or model-controller, such that this core class need not be tainted by view-specifics; you then simply select the right one for the current gamestate and the current entity being rendered, either in your root controller or root view for that state, and say entityViewForThisSpecificGameStateAndThisParticularEntity.render()
(a Javaesque name if ever you saw one). So if you have one IEntityView
component for a minimap, and another for your main game viewport, then each of these holds a reference to the core model or model-controller for that entity, meaning you are indeed sharing key data.
Method 2: Monolithic renderer class, separate from core Entity controller
Here you use a "raw" renderer based approach as common with e.g. OpenGL. Each monolithic renderer pertains to a particular game screen, and will typically be the root view for that screen. You will, inside this monolithic renderer, run through a massive list of entity models or model-controllers (again, nothing view-specific should really be in there!) and render directly inside a single monolithic update function. Again you are sharing key data, but in this case you do not have additional components for every entity; instead the monolithic renderer know everything it needs to know about how to render any entity for this particular screen, given only that entity's data model.
Method 3: Monolithic renderer with pure memory efficiency (TL; DR)
This applies not only to rendering, but to everything. The best possible way to access memory is in large, contiguous blocks where data accesses are, if possible, aligned to the cache width of the system in question. This is often lost in OO, as objects are allocated all over the heap. Refer to the final part of Mick West's Evolve Your Hierarchy... If you ignore all OO structure and aim simply for massive chunks of data, you avoid additional pointer references, which accesses cache, which if there is a cache miss, results in a callout to the heap. This is a serious approach for power users only, as it largely foregoes the nice, human-readable structure which OO provides. As the Tao of Programming reminds us,
You must understand the Tao before transcending structure.
Pros, cons to each? The first approach is easiest to conceptualise as it is a nicely encapsulated system and obeys OO principles nicely; however, it is less efficient as more object references bouncing around means (a) more 32-bit pointers and (b) more potential calls out to heap memory, and furthermore it can be restrictive when you need to play tricks with render order and can also introduce issues when comparing stateful vs stateless rendering subsystems (eg. Flash DisplayObject vs Flash BitmapData, if you know those). In deferred rendering on the GPU, the monolithic approach is preferred, as controlling rendering order is a matter of critical importance. Obviously the third approach is only for if you are trying to milk serious performance out of your system, yet for any VM-based platform (Java, Flash, Unity) performance gains are not as cut and dried as we might like, since both the OS and the VM implementations will muddy the water in terms of what might, in native code, be a clear performance gain.