Timeline for How to avoid violating the SRP in a class to manage caching?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 22, 2015 at 21:25 | comment | added | kevin cline | @DocBrown: The problem is that as written it is untestable. The timing logic (testable) is coupled with the database logic, which much then be mocked. Once a seam is created to mock the database call, you are 95% of the way to the generic solution. I have found that building these little classes usually pays off because they end up being reused more than expected. | |
| Nov 22, 2015 at 21:18 | comment | added | kevin cline | @raven You can test TimedRefreshCache by using a short interval (like 100ms) and a very simple producer (like DateTime.Now). Every 100 ms the cache will produce a new value, in between it will return the previous value. | |
| Nov 22, 2015 at 21:16 | comment | added | Dieter Meemken | I personally don't like your answer because of it's complexity. It is very generic and very abstract and may be best in more complicated situations. But in this simple case it is 'simply to much'. Please take a look at stijn's answer. What a nice, short and readable answer. Everybody will understand it imediatly. What do you think? | |
| Nov 22, 2015 at 21:13 | history | edited | kevin cline | CC BY-SA 3.0 |
deleted 2 characters in body
|
| Nov 22, 2015 at 14:06 | comment | added | raven | @kevin, I'm not experienced in TDD. Could you elaborate on how would you test TimedRefreshCache? I don't see it as "very easy", but it could be my lack of expertise. | |
| Nov 22, 2015 at 11:50 | comment | added | Doc Brown | I agree that if the refresh logic gets more complicated than in the example, it might be a good idea to refactor it into a separate class. But I disagree that the class in the example, as it is, does too much. | |
| Nov 21, 2015 at 22:02 | history | answered | kevin cline | CC BY-SA 3.0 |