4

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.

AntonioHS
  • 187
  • 1
  • 9
  • 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? – AntonioHS 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
  • @edalorzo that's a good point. – AntonioHS Dec 24 '14 at 15:28
  • @Hey, well, I'm trying to apply a general caching pattern to a genericDAO from which all the DAOs in the system will inherit basic functionality (readAll, readByAttributes, executeSpecificQuery, etc). So the goal here is to be able to use any DAO deciding wether or not it will be cached depending on the context. – AntonioHS Dec 24 '14 at 15:30
  • @Hey I think memoization is an alternative that uses a more functional approach. In this case functions are memoized by wrapping them into another function that is smart enough to use a cache when necessary. The proxy sounds more like OO approach. I guess depending on the implementing language one or the other could be more easily achieved. – edalorzo Dec 24 '14 at 15:34
  • @edalorzo, the implementation language is PHP. – AntonioHS Dec 24 '14 at 15:39
  • @Hey If I understand correctly the memoization pattern, it would be like having an "in object" cache, so it wouldn't go to the database twice for the same call. But in my case I wan't to cache the results also between different requests, using memcache or a similar engine. Did I understand correctly about memoization? – AntonioHS Dec 24 '14 at 15:40
  • @antonienko memoization could be either per-request or persistent, using something like apc or memcached. I was thinking that for caching it across multiple requests, dropping in a memoization language extension could save you a lot of work. – Hey Dec 24 '14 at 15:43
  • @Hey I will take a look at that. Any reference you can point me to? – AntonioHS Dec 24 '14 at 15:46
  • 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](https://github.com/arraypad/php-memoize). – Hey Dec 24 '14 at 15:50
  • @Hey, I did a little research about memoization, and I think it doesn't fit in here: First, I need to be able to remove elements from the cache (for example when an update occurs in the database), and I don't see how to do that. Second, the granularity of the cache is at a function level, so let's say I have a function that returns a collection of objects: I could have those objects cached individually so other functions benefit from that cache. I don't see how to do that with memoization. – AntonioHS Dec 24 '14 at 17:26
  • @edalorzo, so in your opinion, if I would implement a decorator that doesn't forward request to the decorated component, that would be like implementing a proxy pattern but with aggregation instead of composition; am I right? – AntonioHS Dec 24 '14 at 17:34
  • @antonienko Some patterns are very similar, but with a different intent. That's the case of a proxy and a decorator yes. So, for me, your decorator working in that manner would be categorized as a proxy, at least in my opinion and understanding of the subject. – edalorzo Dec 24 '14 at 17:37
  • @edalorzo But if I want to be able to use cache or not seamlessly, wouldn't a decorator pattern fits better since it ensures that both classes implement the same interface? I guess I can also do it with a proxy where both objects share interface... – AntonioHS Dec 24 '14 at 17:39
  • @antonienko So does the proxy. The proxy is an implementation of the interface that forwards requests to the proxied object. Now that we talk about it I think in essence it looks like a decorator, in intent it is slightly different as per my comment above about forwarding the request. – edalorzo Dec 24 '14 at 17:42

2 Answers2

4

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.

edalorzo
  • 2,634
  • 1
  • 19
  • 28
2

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.

Jules
  • 17,614
  • 2
  • 33
  • 63
  • 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? – AntonioHS 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