A user on our forum — going through the teething pains most of us experience when learning IoC — asked us about Strange’s suitability for use with Unity. I was happy to oblige with something of an empirical defense: look at our user base, all the studios, all the cred we have inside and outside Unity. Of course Strange is suitable!
But still, I conceded, suitability for some cases doesn’t automatically imply that Strange is right for him or his project. It’s not a one-size-fits-all question. Rather, the answer lies somewhere on a continuum. So how do you know if Strange is the tool for you and your project? So glad you asked!
Strange has several advantages — and a few disadvantages. The more your intended project plays into these strengths, the more likely you would want to apply it. And even when applying it, a sensible understanding of the weaknesses should help you understand exactly where in your product Strange is best applied. In this post, I want to suggest some metrics by which you can make these decisions, none of which will be affected by the upcoming release of StrangeIoC 1.0.
Perhaps more than anything, Strange is a tool for dealing with code complexity. Is your project likely to be complex? If I’m throwing together a quick example, or building Tic-Tac-Toe, I’m probably not going to be motivated to use Strange. The bigger my project, though, the more likely I will want something to handle my dependencies in an elegant manner.
There can be no denying that Strange has a learning curve. For some, it’s pretty steep. To use Strange, you and your team need to learn to use it. They need to understand not just how Strange works, but why. The end benefits are pretty impressive, but only if they’re used according to the manufacturing instructions. If you’re just learning how to code, it might be good enough simply to know that we exist. Learn the basics and come back when you start to understand why code decoupling is a problem you want to solve. Similarly, if you doubt your team’s ability to circle up around a framework, don’t worry. Just put the blame on us.
Team size is also an issue of code complexity, with a slightly different twist. In this case, we’re thinking about the myriad styles in which different coders code. This difficulty can be mitigated with coding standards, but just as every writer has a distinct voice and syntax, so every coder implements ideas in her own inimitable style. That’s great up to a point. But when you have a large team and a tight deadline, ironing out these differences such that I can jump into your code and you can jump into mine can be the difference between making a deadline or not. Opinionated frameworks like Strange tend to urge you to code in a particular way, leading to greater homogeneity. For lots of common problems, the architectural solutions become obvious and automatic, so you don’t need to spend time thinking about them. When you move from class-to-class (or even from project-to-project!) the code looks familiar and you can get right into it with minimal learning.
Additionally, Strange’s management of multiple Contexts means that teams or team members can break a project into sub-modules. Each module can be built independently, then joined up near the end of the development process.
Another key selling point for Strange is its inherent resilience to change. A simple project is unlikely to change much. A real product operating under real world circumstances (with customers, producers, product managers, data analysts, etc. all urging you for fixes, new features and enhancements) might alter considerably. And these alterations may not be predictable or under your control.
The more volatile your project and environment, the greater the odds that you need the ability to adapt.
“How much performance do you need?” The knee-jerk reaction, naturally, is “all of it”, and that’s fair enough. Strange manages performance hits related to reflection, but even with that, there’s always going to be modest overhead related to requesting an injection. Usually, this is tiny when compared with driving your visuals or running an AI algorithm, but even so, we, like you, want to minimize overheads. For this reason we typically suggest keeping your Strange-related activities to a minimum in your most performance-hungry loops.
So be realistic about your performance needs. In a turn-based game or even for occasional events in a shooter, Strange’s overhead is negligible. The nearer your game approaches the realm of performance junkie, however, the more you want to limit its activities.
Unit testing is a huge win…some of the time. It can also be a burdensome time-sink. Which one it is for you is a matter of experience, expertise, and personal preference. Generally, I find that testing my models and services is advisable. Testing controllers depends on complexity. Views are often hard or impossible to test. Whatever your opinion, if you value testing at all then offloading code away from MonoBehaviours makes unit testing possible. You don’t need Strange to do this, but it sure helps.
I’ve not had much trouble with this, but it’s possible you might. One of the very first wins I personally got from using Strange was isolating nGUi into a handful of View classes, thereby keeping it away from everything else. When uGui came along, refactoring was a breeze. Some assets unsurprisingly employ tactics that Strange philosophically opposes, such as using Singletons or attaching non-View logic to MonoBehaviours. Again, for me this has been a net win for Strange, because I can isolate those “bad” practices, wrap them in an interface, and keep them from infecting my code base. If I someday decided to swap one asset for another, I have minimal refactoring to do, since I never let them get out of control.
Now, I can’t guarantee that you’ll never run across an asset that doesn’t play well with Strange. Let’s assume you do. In that very rare case, you may need to shoehorn some logic in a weird, crazy patch. Disaster? Not in my book. If 90% of my code is well-managed, I’ll gladly accept 10% patched together. I’m still beating the odds handily.
Unity deploys to an awful lot of platforms. Strange hasn’t been tested on all of them. We’re good for the obvious stuff (iOS, Android, standalone and web). Follow this link for the complete list of platforms where we’ve validated our framework.
Are we Strange yet?
As you can see, Strange offers many advantages as your code gets complex and volatile. Among these are insulation, flexibility, modularity, and testability. It also comes with a learning curve and some very modest performance costs. So is Strange right for you? I think you’re ready to answer for yourself.