# Asset Library Class or passing Asset's through constructors

I am at the point of designing UI-Logic and I was wondering what a good way to pass asset information to these objects would be.

What I was trying as of yet was passing assets to the objects representing UI-elements through their constructors, leading to code where I pass between 1 to 10 assets (like "button idle" "button being hovered" and "button active" etc.) to the objects or having to create "metaclasses" that define the "look and feel" of these objects that need to be passed to the ui-elements to handle the rendering.

A way I thought of handling this in a "dirty" way was to create a singleton "asset database" that is globally accessible. As every button need's it's own callback function on click it can also get it's own rendering function from where the button can pick it's assets from the accessible assets.

What is a common way to handle this?

I'd wrap all those ten assets up into a type representing a "style." You can either do this generically, so that you have a single Style class that uses some kind of associative mapping from element keys to textures or other assets:

class Style {
TextureReference getTextureAssetFor(String key);
SoundReference getSoundAssetFor(String key);
};


Or you have specific style types for each widget, such as ButtonStyle and SliderStyle and so on, each of which just have a simple list of fields pointing to the various asset categories required by widgets of that type.

Then your widget constructors take one of those, either a generic Style or the type-specific style, depending on your preferences.

The type-specific style method requires more boilerplate work on your part, but means errors such as trying to access the wrong "kind" of asset by misspelling the key name or whatever are caught at compile time. The generic style approach requires a little more up-front engineering and has some runtime overhead, and also makes it easier to make errors that aren't detected until runtime, but it also is more extensible to future widget types and subclasses.