I'm building a php system with the Services/DAOs/Domain Models pattern, and now is the time to implement a caching system for the DAOs.

Would you use a decorator pattern, or maybe the strategy pattern?

What are the ups and downs of each one?

added requirement: Like I told in a comment answering to edalorzo I need to be able to use the DAOs without any caching at some moments. For the same method sometimes is acceptable to have cache, but some other times is not.

  • 1
    Actually I have seen this most commonly implemented as a proxy pattern. – edalorzo Dec 24 '14 at 15:08
  • Well, first of all I must say that I'm quite new to the design patterns world; so let's say that the difference between the decorator pattern and a proxy pattern in which the delegate class is injected (talking about a dynamic language) is not quite evident. Also, since I need to be able to use the DAO with or without cache, I guess is a better option to have the cache object implement the same interface than the DAO, hence the decorator pattern. Do you have any tip why a proxy pattern would be better than a decorator one? – antonienko Dec 24 '14 at 15:25
  • 2
    Well, I am certainly not a world class expert on the subject, but I think the conceptual difference here is that the decorator is supposed to forward requests to its decorated component object. It may optionally perform additional operations, before and/or after forwarding the request, but the forward always happens. With a proxy the story is different, and in the case of a cache you may decide never to forward the request to the proxied object if the cache is still fresh and alive. – edalorzo Dec 24 '14 at 15:25
  • What would be the advantage of using patterns like that over just memoizing a method or two on the DAO? – Hey Dec 24 '14 at 15:27
  • 1
    @antonienko I haven't used PHP in a long time so I can't recommend anything, but take a look at arraypad/php-memoize. – Hey Dec 24 '14 at 15:50

I have seen the implementation of caches using a Proxy pattern. Particularly frameworks like AOP make use of proxies for most of these things.

According to the book Design Patterns and Elements of Reusable Object-Oriented Software the decorator and proxy pattern may look alike/

Page 216:

"Although decorators may have similar implementations as proxies, decorators have a different purpose. A decorator adds one or more responsibilities to an object, whereas a proxy controls access to an object.

Proxies vary in the degree to which they are implemented like a decorator.A protection proxy might be implemented exactly like a decorator. On the other hand, a remote proxy will not contain a direct reference to its real subject but only an indirect reference, such as a "host ID and local address on the host". A virtual proxy will start off with an indirect reference such as a file name but will eventually obtain and use a direct reference"

It looks like your purpose with the cache is to avoid giving direct access to the real subject, so it sounds more like a proxy to me.

The comment above also clearly makes evident that an important difference between a proxy and a decorator is that the proxy may be responsible for instantiating or getting access to the real subject, whereas in the case of the decorator is kind of expected that such reference will be dynamically provided.

It would seem that the relationship between the proxy and real subject is more static than in the case of the decorator.

That being said, ultimately in you case is a matter of intent more than how the design will look like. At the end the solution is to have a wrapper object (either called Proxy or Decorator) that will intercept the method and allow you to control when to gain access to a cache or not depending on your cache policy.


I've implemented it both ways in the past, and my experience has been that using a decorator results in a clearer separation of responsibilities between the two classes, as using a strategy requires support in the data access class, whereas with a decorator you write the data access class the same as you would if you weren't implementing cacheing.

  • While I see a valid point in your answer, do you have any opinion on the decorator vs proxy discussion that we engaged on the comments to the question? – antonienko Dec 24 '14 at 17:37
  • In my opinion the definitions of patterns are not rigid, so I think the argument that because not every call is forwarded it isn't a decorator is spurious. The intent of the decorator pattern is a closer match, so I prefer calling it a decorator. But in the end, everyone will know what you mean whichever name you use, so I don't think it really matters. – Jules Dec 24 '14 at 18:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.