1

I'm actually reading about the Proxy design pattern (https://refactoring.guru/design-patterns/proxy) and I'm wondering about what does prevent the Client to call directly the RealSubject class.

I give you this illustration that i've found on this post :

enter image description here

I can't understand how to prevent client for making the mistake of calling the RealSubject directly instead of the Proxy object.

What I would like to do is to obligate the client to call the Proxy object, so the Proxy object can filtering access and logging access ect...

I've even buy this book and read the part about Proxy, and have also looked at the code example which is given :

...
Proxy design pattern code
...
echo "Client: Executing the client code with a real subject:\n";
$realSubject = new RealSubject();
clientCode($realSubject);

echo "\n";

echo "Client: Executing the same client code with a proxy:\n";
$proxy = new Proxy($realSubject);
clientCode($proxy);

So here in this code snippet it seams to be allowed to call directly the realSubject without using the Proxy.

So maybe I'm not looking at the good design pattern, maybe there exist one which would suit my requirement of forcing client to call the 'Proxy', and not allow to call the RealSubject ?

5

I'm wondering about what does prevent the Client to call directly the RealSubject class.

In general, nothing prevents this. That doesn't mean you don't have mechanisms you can use to prevent this, but in general they won't be a "design pattern" per se; design patterns are not the be all and end all of good software engineering.

Some ways you can prevent (or at least reduce) calling RealSubject directly:

  1. Code reviews. If you see anything other than the proxy calling RealSubject, you reject the code.
  2. Scope RealSubject so it is not visible to the client code (may or may not be possible in your language).
  3. When creating your DI container, make sure the proxy is registered and RealSubject is not - this makes it much harder for anyone to accidentally call RealSubject.
  4. Static code analysis in your CI system which errors on any direct calls to RealSubject.

Many more exist, which ones are appropriate for your environment is something you'll have to work out. Personally, I've never found a need for anything other teaching/reminding developers and code reviews.

| improve this answer | |
  • If you're language permit stack analysis (like .net does) and you have a compile time switch (to compile out the snopping if you want to, say for a production build), you can have the real object analyse the stack and verify it was called via the proxy. If it wasn't log the stack trace/other information to the console/attach a debugger/and all the other fun stuff such detection code can do. – Kain0_0 Sep 17 at 9:11
  • @Kain0_0 I did think of stuff like that, but it would be (massive) overkill for the industries I've worked in. I can understand it might be appropriate if RealSubject were actually PatientMedicalDataExporter. – Philip Kendall Sep 17 at 9:14

Your Answer

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

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