Static constants

rob.johansen's Avatar

rob.johansen

21 Oct, 2011 06:44 AM

Hi all,

I'm very excited to be working on my first Robotlegs application!

My application will allow the user to set a color theme. I was thinking about using static constants for the color names until I came across this post, which recommends using value objects instead of static constants.

I have a few questions about that post, and the concept in general:

  1. What is the benefit of injecting against interfaces? I still need a little help grasping this concept.
  2. Do I need a separate interface for each color?
    var blueVO:ColorVO = new ColorVO(0x1822C1);
    var grayVO:ColorVO = new ColorVO(0x919191);
    injector.mapValue(IBlueColorVO, blueVO);
    injector.mapValue(IGrayColorVO, grayVO);
  3. Once I map the value objects in my context's startup() method, do I have to inject all the colors into every class that needs them? (This seems like a lot of work.)
  4. Also, when I inject the colors into my classes (using the [Inject] metadata tag), I should inject the interfaces, right?

Thanks in advance for any help!

  1. Support Staff 1 Posted by Stray on 21 Oct, 2011 09:34 PM

    Stray's Avatar

    Hi Rob,

    when you inject against an interface you're building your classes to use a contract, but without binding them to a specific implementation of that contract.

    For example - if you inject an IUserAuthorisationService then you can implement that as a RemoteUserAuthorisationService and a TestUserAuthorisationService - allowing you to have your app 'authorise' a user before the back end service is actually available.

    That's one of the main tangible benefits anyway - being able to compile your app in a state that makes it quick and easy to test or for a client to get straight to the part that you want them to give you responses to.

    On a higher level, when you build against an interface you're freed of any thoughts about "how" stuff gets done - and you can think in terms of that contract more cleanly.

    I wouldn't map those two VOs as individual values. I'd be more inclined to have a ColourSwatchVO (with an interface) and have properties .blue and .green on that item.

    I'm slightly worried about the idea of injecting colours though... perhaps a bit of info on your use case would reassure me? If you're doing skinning or similar then there are neater ways to achieve this.

    In short - you are right that "I have to inject X all over the place" is a code smell!

    hth (sorry about your question being stuck in spam)

    Stray

  2. 2 Posted by rob.johansen on 21 Oct, 2011 10:13 PM

    rob.johansen's Avatar

    Thanks very much for your response, Stray (and thanks for pulling my post out of spam).

    My use case is, in fact, skinning. I was planning to provide a series of small buttons along the bottom of the application that allow the user to change the color theme. It will be pretty simple: Click the blue button and a predominantly blue background image is displayed, while other visual elements (e.g. Sprites) change to a shade of blue. Click the red button...same idea.

    When the button mediators handle the click events, I was originally thinking of having them dispatch a custom event (ThemeChangeEvent) into the context that carries a property for whatever the new color should be. I thought a command could handle this custom event and make a call to a service that loads the appropriate background image. Since these colors will never change, I thought maybe I should use static constants...then I thought value objects...now after your post I'm not sure how best to handle this.

    Any suggestions based on my use case?

    Thanks,
    Rob

  3. 3 Posted by Stray on 21 Oct, 2011 10:47 PM

    Stray's Avatar

    Hi Rob,

    I'd make a SkinningFactory class (that implements an iFace) and inject that into your mediators.

    In onRegister, pass the instance of the view to the SkinningFactory and have the factory do the magic by passing the assets / colour parameters to the view.

    You'll probably want to use the view class to look up in the SkinningFactory what to actually give to the view. (And of course you'll inject the SkinningFactory against ISkinningFactory in your view).

    Then you can hold a list of the views that have been skinned already (so that you don't do them twice if they come and go from the stage).

    When your mediators pick up the ThemeChangeEvent they can pass their views to be skinned again (and you drop the cache on the SkinningFactory when the colour changes, so that any view is 'fresh meat' to be reskinned). And you'll have used a Command to update the current theme that the SkinningFactory should use.

    Does that make sense?

    Basically you want to abstract this functionality into something nice and separated.

    I hope that makes sense? Of course there are a ton of other ways to do it too but this is my preferred method - I've tried many and this one keeps me sane!

    Stray

  4. 4 Posted by rob.johansen on 22 Oct, 2011 01:03 AM

    rob.johansen's Avatar

    That makes sense. Thanks for the help.

  5. Ondina D.F. closed this discussion on 01 Nov, 2011 04:07 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac