Bummer! This is just a preview. You need to be signed in with a Pro account to view the entire video.
Singleton Pros and Cons2:30 with Bjorn Chambless
Singletons are not the answer to every problem. Like any tool, you must be sure that you are using it in the correct context or it can further complicate your work.
- Singletons Hinder Unit Testing.
- Singletons Create Hidden Dependencies
How to avoid these pitfalls
- Make certain your class should be a singleton
- Consider unit testing when designing the singleton architecture
- Use dependency injection when possible
- Singletons by Matt Galloway
- UIDevice on iOS Dev Diary
- Factory Methods
- Lazy Instantiation
- XCode Project Templates
- Static Keyword in C
- Concurrency Programming
- instancetype on NSHipster
- Mac File System Programming Guide
- Grand Central Dispatch In Depth
- iOS Unit Testing
- Dependency Injection
Singletons are not the answer to every problem.
Like any tool, they can be misapplied and overused.
Some developers are critical of Singletons for various reasons.
We'll examine these critiques and discuss ways to address them.
The criticisms for the most part fall into two categories.
Singletons hinder unit testing A singleton can hinder
unit testing when objects, and their methods become dependent upon it
to the point of being untestable without a fully functional singleton class.
Unit testing relies on the ability to test a method, object, or
module in relative isolation from the rest of the code base.
Integration or coupling with objects
which hampers the ability to isolate a test target is problematic.
Singletons with complex interfaces and
significant internal state can make unit testing more difficult.
Singletons create hidden dependencies.
Since the Singleton reference is readily available throughout the application,
through a class mended, it can be overused and since the reference is not
explicitly passed, the dependency on the Singleton can be difficult to track.
To avoid these complications, when considering the Singleton pattern,
developer should Make certain your class should be a singleton.
A class should be a singleton if there can and should be only one.
If there is a question as to whether uniqueness is appropriate,
it probably isn't.
Consider unit testing when designing the singleton architecture.
Unit testing should always be a consideration, but
singletons should be given special attention.
A simple interface that can be simulated as a test-harness is recommended.
The singleton should provide an interface that hides complexity, and
allows for the implementation to be swapped out for testing.
State stored in the Singleton should also be minimized.
Use dependency injection when possible.
Dependency injection is the explicit
passing of a reference to expose dependency.
Though any class can access the singleton reference through a class method,
this should be done sparingly.
One possible past the singleton as an init method parameter when objects are created.
You need to sign up for Treehouse in order to download course files.Sign up