One is a copy constructor which can be invoked in several circumstances.

A a;  // Normal constructor.
A b( a ); // Copy constructor.
A c = a; // Copy constructor.
 

L. Spiro

There may be a more general solution to your problem, and that is to use Entity Component System design pattern. In principle:

1. The Entity is a general purpose object. Usually, it only consists of a unique id and a container.
2. The Component consists of a minimal set of data needed for a specific purpose. In your example, you would have a "Visible" component and a "Physical component".
3. The System manages the behavior of the components.

In your example, a human would be an Entity with a "Visible" and a "Physical" component attached to the container. A Component can have a state, but it doesn't have to.

And then you would have one system that manages all Entities that use the "Physical" components, and another system that manages all entities with "Visible" components. These systems would be independent of each other. There may be variations, where a System need to access entities that consists of a combined list of components.

See Anatomy of a knockout and Refactoring Game Entities with Components for more information. I think the https://github.com/alecthomas/entityx source code looks promising. It also has a good support for using events to communicate information between systems (and other modules), instead of having components know about other components.

The disadvantage of the ECS may be that it adds some code initially, and it also adds some communication overhead. If you have a small system with not much more than stated above, then ECS will probably be an overkill. The advantage is that it has a very high degree of flexibility. It is much easier to add functionality, and provide alternative functionality.

Hmm, ECS seems interesting, so according to my research, I would have Human( an entity) and instead of inheriting visible and physical, it has instances of visible and physical?

Right. Now suppose you have a drawing function. This would be a "System" that iterates through all entities that have both a physical and a visible component, and draw them. The visible component could typically have some information about how a thing should look like (e.g. human, monster, sparks flying around, flying arrow), and use the physical component to know where to draw it.

Another system could be a collision detection. It would iterate through all entities that have a physical component, as it wouldn't care how the entity is drawn. This system would then detect "arrows" that collide with "monsters", and generate an event when that happens. It shouldn't need to understand what an arrow is, and what it means when another object is hit by an arrow.

Yet another component could be health data, and a system that manages health. Health components would be attached to the human and monster entities, but not to arrow entities. The health management system would subscribe to the event generated from collisions and update health accordingly. This system could also now and then iterate through all entities with the health component, and regenerate health.

Of course a real game is much more complicated than this, and there are new design problems to solve. But I think the ECS way is interesting. Using events isn't part of the original ECS pattern, but I think it is convenient and will decouple dependencies.