Thanks! Super quick reply too :)
I ended up with something similar to what you suggest.
In my Context:
I am guessing that it's overkill to use a command in my above
code when a service can just call another service. Guessing to it
is better practice not to make my singleton 'accessible to all' and
just accessible to what needs it. I'll update to your code :)
Slowly things are becoming more understandable to me.
Support Staff4 Posted by Ondina D.F. on 29 Jun, 2012 02:57 PM
No problem, Andy:)
Maybe my first statement was a bit misleading.
I should have warned you that creating an instance of
CreateDefaultSettingsXMLService in another service may be
How will you know when to destroy it, in case of an asynchronous
response, and where are you intending to destroy it? Or are both
services disposable after running them?
Besides, it’s not quite “nice” to call a service
from another service, if you want to strictly follow the best
But, if you really need to do it like that, just do it. You can
decide later whether it’s a good approach or not.
afraid it's me again :)
Digesting this part of your first message:
-In SomeCommand : [Inject] public var someService: ISomeService;
then access someService.loadSomething()"
You've probably guessed it but I've a Q or 2!:
-does RobotLegs only instantiate a service when it is called? Most
likely this is a stupid question :-) -regarding
"injector.map(ISomeService).toSingleton(SomeService);" Why use
ISomeService and not just injector.mapSingleton(SomeService)? Is
there a memory benefit of not referring to the 'full fat' class and
referring to it's interface?
Support Staff8 Posted by Ondina D.F. on 02 Jul, 2012 02:10 PM
this is robotlegs 2? map method not available to me
Right, this is rl 2 syntax. My bad, I was working on an rl2
project by the time I answered your question, and the more
intuitive syntax used in rl2 was still fresh in my mind.
For rl1 the mapping would look like this:
Regarding the question about interfaces:
It’s impossible for me to cover all the benefits of
“Programming to an interface, not an implementation“ in
this post. The topic is too complex, and besides there are a
multitude of in-depth articles and books on the subject, written by
experts. So I’ll just mention a few things (rather keywords
that can be used for further research) that come to mind:
using interfaces enables code reuse, which can minimize
duplicate and repetitive code, the code becomes flexible, managing
dependencies is easier, your application is easily maintainable
using interfaces makes it possible to follow the SOLID principle
of OOP and OOD
interfaces are used in several design patterns
interfaces as APIs
interfaces keep the coupling minimal
encapsulating the implementation is a good thing
you can be sure that a certain functionality will work in a
you get compiler errors when the class that implements an
interface does not implement all the methods declared in the
interface, and that’s good when building an application that
will be extended by another developer or used by third parties
it is easier to test classes in isolation and to use mock
objects when real objects are not available
generalization is a good thing, in OOP ;)
allows the use of interchangeable behaviors, variation of
using an interface allows a service to be swapped for another
one that implements the same interface, i.e., if IAssetsLoader is
implemented by SQLAssetsLoader , XmlAssetsLoader, MockAssetsLoader
, all you have to do is replace
injector.mapSingletonOf(IAssetsLoader, MockAssetsLoader);// a dummy
class used to mimic services’ behavior – used in unit
This way your Application doesn’t have to care where the data
Sorry, if you already know all of this, or if the random listing
was confusing! :)
And don’t worry, compared to the design patterns gods and
geniuses out there (GoF, Fowler and many others) we, ordinary
(mortals) coders, will be Noobs Forever;) No matter how advanced we
get, they’ll be always ahead of us, unless the best practices
and design patterns change over time…
Besides, being a perpetual newbie in a programming/platform field
or another is our fate as developers, am I right?
You can close the discussion, in case your original problem has
been solved. Please open new threads for new issues.
Thank you :)