1

I have a third party library class Lib and an own LibProxy where LibProxy adds some caching before passign the control to Lib. This would have been textbook Proxy, but LibProxy also simplifies the interface to Lib. Which also makes it a Facade.

What is the course of action here? Making LibProxy comply to the interface of Lib and adding a separate LibFacade feels like overkill. This is what it would look like: Client->LibFacade->LibProxy->Lib.

Can I call it LibProxyFacade instead? Or is there some other pattern that is equivalent to the Proxy/Facade combination?

mlntdrv
  • 137
  • 1
  • 8

1 Answers1

1

I would say don't overthink it: the patterns are there to show us a way of solving some of the common problems, but it doesn't mean they are always the right/only way. I like this talk by Venkat where he is presenting some patterns, but he starts the presentation with the cons of overengineering: https://youtu.be/yTuwi--LFsM?t=238

Back to your question: does ProxyLib really need to implement the same interface as Lib for any reason (other than following the Proxy pattern)? Why not change the interface (and maybe rename the class to something else like LibFacade or LibAdapter?

If you want to implement an interface, I would place it in inside your domain, and have this facade/adapter implement it by mapping, adding some caching, and delegating to Lib. This is called dependency inversion and helps you protect your logic against the changes in the public API of the lib. If this is interesting to you, here is a blog post from Uncle Bob: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Emanuel Trandafir
  • 1,526
  • 1
  • 5
  • 13
  • Thank you for your suggestions. LibFacade may be a good option, but then it doesn't convey the intent about caching that LibProxy had. I am still wondering which of the two is more important. :) BTW in my language, DI is kinda built in - a class is also an interface, no need to create an explicit interface. – mlntdrv Apr 19 '23 at 14:46
  • I see, but still: if you use the raw types/objects specified y the lib, your logic will still depend on it, even if it is your interface, it's not a true DI - if you know what I mean. In other words, you won't easily switch to a different lib if needed. On the other hand, if you create your own abstraction (by making the API more friendly/simplifying it, as you already said) you will have more flexibility. – Emanuel Trandafir Apr 19 '23 at 15:36
  • I depend on the interface of `LibProxy` (the simplified one), not on `Lib`'s. – mlntdrv Apr 20 '23 at 06:51
  • is it ok then :) – Emanuel Trandafir Apr 20 '23 at 07:36