0

Let's say for a Net Core library that I will deliver to the customer

The library define a Interface like IGetData and also a default GetData class.

The library also define a ICacher interface with a default Cacher class

It's the client's responsibility to register the Interface and the default Classes to their DI container. They can also define and register their own Cacher

My question is :

1/ Is there something wrong with this design ?

2/ Normally how a dependency that is optional should be handled ?

3/ In the case that the optional dependency is handled correctly, my GetData class would contains something like

If(Cacher != null)
return Cacher.GetData()

Is this also normal?

  • 1
    using the null object pattern is often preferable to explicitly checking for nulls. So instead of making the dependency optional, provide a default implementation that does nothing. – amon Jan 9 at 9:28
  • Caching should be transparent to the user. Cache should be decorator of the API. It should not have different API. – Euphoric Jan 9 at 9:38
  • @Euphoric I am not sure I understand. For me I feel like the user can implement their own ( Redis / Local / Memcache ... ) Caching classes. They just have to follow the Interface of ICacher.GetCache / ICacher.SetCache In this specific case, I only provide a local Cache solution – qkhanhpro Jan 9 at 9:41

Your Answer

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

Browse other questions tagged or ask your own question.