When not to use Proxy Design Pattern?

• Overhead for Simple Operations: Avoid using a proxy for simple objects or operations that don’t involve resource-intensive tasks. Introducing a proxy might add unnecessary complexity in such cases.
• Unnecessary Abstraction: If your application doesn’t require lazy loading, access control, or additional functionalities provided by proxies, introducing proxies may lead to unnecessary abstraction and code complexity.
• Performance Impact: If the introduction of a proxy negatively impacts performance rather than improving it, especially in cases where objects are lightweight and creation is not a significant overhead.
• When Access Control Isn’t Needed: If there are no access control requirements and the client code can directly interact with the real object without any restrictions.
• When Eager Loading is Acceptable: If eager loading of objects is acceptable and doesn’t affect the performance of the system, introducing a proxy for lazy loading might be unnecessary.

The Proxy Design Pattern is a structural design pattern that provides a surrogate or placeholder for another object to control access to it. This pattern is useful when you want to add an extra layer of control over access to an object. The proxy acts as an intermediary, controlling access to the real object.

A real-world example can be a cheque or credit card as a proxy for what is in our bank account. It can be used in place of cash and provides a means of accessing that cash when required.

• And that’s exactly what the Proxy pattern does – ” Controls and manages access to the object they are protecting”.
• As in the decorator pattern, proxies can be chained together. The client, and each proxy, believe it is delegating messages to the real server: