Bummer! This is just a preview. You need to be signed in with a Pro account to view the entire video.
Refinements4:06 with Bjorn Chambless
Refinements are added to singletons to make them more robust. Fool-proof implementation so that it becomes difficult for a developer to accidentally break your singleton.
One downside to our “fool-proofing” is that it complicates potential subclassing since an instance of a child class can no longer call
[super alloc] as we have in our
-hiddenAlloc method. Also
[[self class] hiddenAlloc] would fail if called by a child class instance unless the child class also implemented
- 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
A few refinements can be added to our Singleton to make it more robust.
One danger to our implementation is that an additional instance of the class
might mistakenly be created, breaking the Singleton pattern and
the intended resource encapsulation.
A new programmer on a project might not be entirely familiar with our class,
or with singleton conventions.
The danger is that despite the availability of the sharedInstance class
method, a developer may simply call alloc and init instead.
We're going to foolproof our implementation so that it becomes
nearly impossible for a developer to accidentally break our Singleton.
We'll continue working on our single object in the same Singleton project.
The goal of our fool proofing is to prevent the allocation of a SingleObject
instance outside of the sharedInstance method.
We need a way to prevent a careless call to
alloc init from creating a Singleton doppelganger.
Our solution is to override the alloc class method, and locate the real
alloc functionality in a hidden class method that we'll call hidden hiddenalloc.
The new implementation of alloc will simply display a helpful log message, and
This should make it clear to anyone calling alloc init that they should be
Our hidden alloc method will provide alloc functionality by simply calling
alloc in the super class.
So, first we, override alloc and
have it return use sharedInstance please,
since we're being polite.
And then we return nil and
then we put the real alloc
functionality in hiddenAlloc.
alloc typically goes up to the super class anyway,
super alloc is equivalent to our old missing
alloc definition, or our missing alloc class.
So the other change we need to make is to
change this to hiddenAlloc instead of alloc.
And we'll just change self.class,
back to singleObject, because as I'll talk about in a minute,
it won't work with sub classing, since we've added this fool proofing.
So, we'll run this in test again, and
in main we've added an additional call to SingleObject,
this attempts to create a SingleObject in
a naive way that we're trying to prevent.
So, executing this code,
we see that the first two calls to shared instance worked properly and
it returns the same Singleton instance, which is good.
These two have the same memory addresses.
And the call to alloc init prints out our helpful message that says to
use shared instance.
As I said, one downside to our fool proofing is that it complicates potential
sub classing, since and instance of a child class can no longer call
super alloc, as we had in our hiddenAlloc method.
Also, self class hiddenAlloc would fail if called by a child class,
unless the child class also implemented hiddenAlloc.
You need to sign up for Treehouse in order to download course files.Sign up