Need some help from OOP mind people. ))
What if I have something like
Item, which can be
Armor or whatever, and I want to render it on the screen.
Direct3D.Render( Item item ) will render it through image path and some APIs, but
Console.Render( Item item ) will render it using just type and name, for example, "Weapon: Frostmourne".
In such approach there is no way to remove type casting or some kind of getters because every rendering method is tightly coupled with render-specific details.
There is no way to generalize RENDERING (?).
There is no way to use inversion of control (what I really want), because
Item cannot depend on concrete rendering implementation.
There is no way to create something like
ConsoleWeapon, because if it's decorator of
Item, it has access to only its public members, but wait, we have only behaviour here...
Generally speaking, the main problem here is that logic of objects representation is conceptually needs to ASK for data (through cast or getters, whatever). But, for example, Yegor's printers (I like them, actually) are based on idea of TELLING object to print itself (or render itself).
How this can be possible, if knowledge of object representation exists only in representation system and cannot be shared with object domain?
Does anyone tried to generalize rendering through some kind of printers?
I agree and really like such approach.
But the problem here is the knowledge about "mesh, textures, etc".
Item cannot have that knowledge. Why?
Well, the easiest answer is just because there is a LOT of such knowledge.
Item will blow. Sometimes I can't even access rendering library from domain model (physically).
The other one is a metaphor of painting: I can represent every object in the world in a tremendous possible ways, and this object doesn't even know about that. Its behaviour remains unchanged.
So this is a question. I can use getters like
getDamage() and render everything easily. This is the approach of most applications. But what if I want to use inversion of control and OOP? What if I want to tell object something like "Hey, render yourself to that canvas"?
I think this is impossible, but maybe guys here have ideas or solutions.
RenderableItemcould be totally different objects.
Weaponcould encapsulate/hide its
damageand have only methods like
RenderableItemcould have textures, etc. (and maybe just the ID of
Weaponso it knows which item it represents), and have a method
Well, this is actually really depends on... But, in my example domain, I need at least one getter with resulting enum
ItemType, so that I know, whether this is
Armor. Then I need to check it's durability to know, should I use broken texture or just simple. Also, it's very common that
Item has rarity, so that I can render blue frame or green or orange etc.
So there will be always GETTERS:
And, as you can see, they depend on representation, not vice versa. I don't know a proper way to do correct encapsulation and OO for such things. Yegor offen says "The whole design is wrong", but it's not even design, it's just simple case. By the way, games development domain is far more richer, than any other, because sometimes to implement some features you must be really close to real world.
What I think is may be a good compromise is when
Item itself declares another interface like
ItemCanvas, that interface must generalize rendering for
Item as much as possible. Then I can implement that interface in game client library and use it for a proper rendering.
As renderer I still depend on some DATA, but this data (behaviour) is concentrated in some specific API, which is not mixed with actual
Item interface. Maybe this is a good compromise, I don't know...