Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm a junior developer and I'm working on a pet project that I want to learn as much as possible from.

I have the following scenario:

There's a WCF service that I use to retrieve and update data, lets say Cars. So it's called CarWCFService and has a GetCars(), SaveCar(), ... . It implements interface ICarService. This isn't the Actual WCF service but more like a wrapper around it.

Upon retrieving data from the service, I want to store them in local memory, as cache. I have made a class for this called CarCacheService which also implements interface ICarService. (I will explain later why it implements ICarService)

I don't want client code to be calling these implementations. Instead, I want to create a third implementation for ICarService that tries to read from the CarCacheService before calling the WCFCarService, stores retrieved data in the CarCacheService, etc.

3 questions:

  1. How do I name this third class? I was thinking about something as simple as CarService. This does not really says what the service does exactly, tho. Is the naming for the other classes good?
  2. Would this naming and architecture be obvious for future programmers? This is my biggest concern.
  3. Does this architecture make sense? The reason that I implement ICarService on the CarCacheService is mainly because it allows me to fake the WCFService while debugging. I can store dummy data in a CarCacheService instance and pass it to the CarService, together with an(other) empty CarCacheService. If I made CacheCarService and WCFService public I could let client code decide if they want to drop the caching and just work directly on the WCFService.
share|improve this question
I think this belongs to SO –  Gaurav Feb 22 '11 at 12:53
I was unsure. Is there a way for me to migrate this to stackoverflow or can that only happen by vote? –  Thomas Stock Feb 22 '11 at 12:59
@Gaurav, naming questions are by their nature subjective, so I think this post is fine here (although I could indeed imagine such a question on SO too). –  Péter Török Feb 22 '11 at 12:59
@Peter On second thoughts I think Q is OK here. –  Gaurav Feb 22 '11 at 13:12
add comment

3 Answers

up vote 2 down vote accepted

Would this naming and architecture be obvious for future programmers?

To me there are too many Services here. How about

  • CarWCFService -> CarWCFAdapter
  • CarCacheService -> CarCache

Then you can call the third class CarService (or CarServiceImpl - after all, I assume, clients won't see the name of this concrete class directly anyway, they will only deal with the interface).

Or a different twist: keep CarWCFService and call the third class CarServiceProxy instead.

Does this architecture make sense?

I would not have CarCacheService implement ICarService. The reason you give is a test implementation detail. I would just mock ICarService in my unit tests instead. (you do have unit tests, do you?)

share|improve this answer
yeah I'm developing this using Test Driven Design for the first time, which forced me to think more careful about this stuff. I understand your point and although I said I'd mainly use CarCacheManager for debugging, I think it's also important that people can quickly see how my application works without depending on an external service. The external service actually talks with Active Directory and MS Exchange Server so it would be nice if I can fake this stuff for demos and developing the GUI. What is your reason not to implement ICarService? –  Thomas Stock Feb 22 '11 at 12:52
@Thomas, well, is it true that a cache is-a CarService? To me it is not. Faking external services in unit tests is what mocks are invented for - use them instead of tangling in your design. There are excellent mocking frameworks around in most major languages. –  Péter Török Feb 22 '11 at 12:55
I like your naming suggestions, but perhaps CarCacheManager would be more appropriate since CarCache sounds like a class that actually holds the storage, instead of a class that provides an interface with the (memory)storage? –  Thomas Stock Feb 22 '11 at 12:56
@Thomas, CarCacheManager would be fine too. Although note that its clients shouldn't care nor know about whether it actually holds the storage or just delegates the work further - it's an implementation detail. –  Péter Török Feb 22 '11 at 12:59
ok, good point. Thanks a lot for your advice and suggestions. Was certainly helpful. –  Thomas Stock Feb 22 '11 at 13:00
show 4 more comments

I'd have two classes, not one. I'd have the cache wrap the DAO. It's essentially the Decorator pattern, where the decoration adds cacheing.

share|improve this answer
add comment

I don't claim it to be perfect, but I usually call classes that can decide their own cache behavior cacheable__ in your case cacheablecarserviceclient would probably be what I call the client piece if I am following your example correctly.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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