> thing good: it ensures, that there will be only one instance of this
> object in a life cycle.
At most there will be an instance of a class, which is an
object, but not of an object.
> So with singleton you would exclude possibility to bypass other caching
> objects. But non-singleton solution doesn't mean that you will have
> multiple instances.
How many would you have, then? And how would you retrieve it
- stored with Zend_Registry? Storing the default cache
instance with a unique key with Zend_Registry, which
actually follows the Singleton pattern, is just that.
> Singleton makes also unit testing more difficult.
Can't say anything about unit testing - haven't explored it yet.
> In other words, I don't see the benefit of singleton pattern, only
> loosing possibility to have multiple instances if its needed, and making
> it more difficult for unit testing
If you have a model class that is equipped with a method
that returns a cache instance, how would returning the cache
be handled?
Retrieve it from Zend_Registry? Then it's Singleton.
Check, if a cache instance has been stored in a non-static
designated property of the model instance, if not, create
and store it, return it? Then you'd have a cache instance
for every model instance.
Check, if a cache instance has been stored in a designated
static property of the model instance, if not, create and
store it, then return it? Then you'd have a single cache
instance for all model instances subclassing the base model
class in which this static property is made available, so,
if all of your models extend this base class, your model
cache instance would be a Singleton.
But, when using a cache, I believe you are interested in
increasing the performance of your application rather than
just using caching because it sounds like fun. So, you will
rather want to work with the least number of cache instances
satisfying your needs rather than wasting resources by
creating countless of them.
Best regards,
Andreas
没有评论:
发表评论