[quote name='Alpha_ProgDes' timestamp='1318700912' post='4872917']
Out of curiosity, is the way you structured your code because of how XNA is structured? Or would you take that approach regardless of the game-dev library you used?
It balances the encapsulation and coupling.
- HudElement doesn't need to expose its internals. It could, for other reasons, but in this case it isn't needed. So HudElement knows how to render itself.
- The container that holds these isn't all that relevant either. If one were to choose array, ArrayList, ..., anything iterable, code remains same (almost).
- Elements to be rendered don't need to be explicitly named. Just render entire container.
Later, one could get fancy. If Hud had to be rendered to something else, one could use delegates or somesuch. If there were multiple containers one could pass the iterator, perhaps custom one.
But code above groups orthogonal concepts.
Advanced topics:
- It's aligned with Inversion of Control, which tends to minimize coupling.
- HudElement is now isolated. Aside from being directly reusable on any SpriteBatch, it can be also tested in isolation.
- foreach contains more contextual information and hints that container is not "clever". If we need something more (specific ordering, subset of elements, ...), it needs to be stated specifically.
[/quote]
Ah, I can't really use your way, I need to be able to have a separate draw method for the different elements so I can calculate the sourcewidth of the Healthbar/Armour etc. Now I think of it, that was the reason for the HUDElements not drawing themselve in the first place, they all need to be drawn differently