Well, this can be good for generic engines like serialization: serializer doesn't care about anything and can work with property-value pairs. But more specific engines cannot.
So the problem with
with( name, data ) is that as RENDERER how do I know, which kinds of names are available and which one is related to durability, damage and etc.? Even if I know, how can I be sure that contract is not changed? Oh, I mentioned word contract because, as you can see, this will be just another way to implement... getters!
It seems like the whole problem to render an item leads us to some kind of getters in one way or another.
@JoshuaLight You don't need
ItemType. Just have interfaces such as
Bag, etc. If you need properties like "durability" for rendering, ask yourself - why? If it's to determine whether it's broken or not, just give it a method
isBroken(). So your
Renderable could encapsulate (not decorate)
Item it's supposed to render and just ask it
Rareness may be more tricky. Perhaps your game
World should have the responsibility of tracking which items are rare and which aren't?
Itemcould have a method
InventorySpecscould have methods such as
Just have interfaces such as Weapon, Armour, Bag, etc.
So you think I should use type-casting? Because only with type-casting I can check whether
Item is weapon or not. Also, there are a lot of weapons here: swords, axes, maces etc. How can I determine which texture to use to render specified
IsAxe()? This approach conceptually is almost like getters, no encapsulation at all.
I think rareness was a bad example, because this is really a property of item, which is needed only to show player that his weapon differs from others on a quality level.
This printers idea with
InventorySpecs is a good one. As I said earlier, it looks like this is a acceptable compromise, if
InventorySpecs is driven by domain model, but related only for
InventoryRepresentation. Then I can create
Direct3DInventorySpecs and so on. We conceptually separated rendering from behaviour. This is still looks isomorphic to getters, but in more elegant and objective way, as for me. Will try it soon on my game, where I test such things.
Scene, and then the Scene might encapsulate other Objects, each of whom is told to render themselves
Drawbased on a Parent Position. The calls propagate downwards until every object in the graph (each encapsulated in a specific group or container) has been told to draw himself.
I like such approach and seen it in many places, actually. But, as for me, it can be used only for UI things in UI domain. Yes, we can abstract rendering for visual things, as it has done in, for example, Avalonia UI, where guys just created something like
SpriteBatch that is used in many OS and contexts.
But when we're talking about separation of domain model from UI (I think this is obvious, why we're doing that), then all become more complicated. I think this is just theoretically impossible without getters.