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.

closed as primarily opinion-based by user40980, GlenH7, jwenting, Kilian Foth, gnat Aug 7 '14 at 0:05

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.


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?)

  • 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
  • 1
    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

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.


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.

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