Important preliminary remarks

First of all, you shouldn't chose a design pattern in a catalogue, because it is trendy or by looking at advantages and inconveniences. You should chose a design pattern if it corresponds to a problem you have and fits in your design.

Also, patterns do not have a one sentence definition. Patterns are defined by a combination of an intent (what's the purpose), and a description of their structure (how the purpose is fulfilled).

THe proxy

This being said, what you describe, is a pattern aiming at changing an object's interface. This would rather be something like an adapter (although it's not a close match here either).

Some other posts in the linked question suggests to use the proxy to add operators. But adding new responsibilities is the aim of the decorator pattern.

The proxy pattern according to GoF has the intent of providing a placeholder object (with the same interface), in order to control access to the original object.

So if you have no special need, there is no advantage for this pattern.

However, there are a couple of scenarios where proxy are really useful. For example:

• if your objects are managed on a remote server, you could have a local proxy that forwards the operations via a network interface to the remote object.
• if your objects are resource consuming and you have them most of their time stored on disk, you can use the proxy to act as placeholder. The proxy would then deserialize the object when it's needed and forward it the operations (e.g. cache).
• if you want to add access control, for example make sure that an object is accessed read-only (by replacing any changing operations by a stub) or making user based access control before really doing the operations (e.g. if the user is authorised, do the operation, if not, throw an access control exception. with the advantage of separation of concerns between object's behavior and access control)

Important preliminary remarks

First of all, you shouldn't choose a design pattern in a catalogue, because it is trendy or by looking at advantages and inconveniences. You should choose a design pattern if it corresponds to a problem you have and fits in your design.

Also, patterns do not have only one sentence definition. Patterns are defined by a combination of an intent (what's the purpose) and a description of their structure (how the purpose is fulfilled).

The proxy

This being said, what you describe, is a pattern aiming at changing an object's interface. This would rather be something like an adapter (although it's not a close match here either).

Some other posts in the linked question suggest to use the proxy pattern to add operators. But adding new responsibilities is the aim of the decorator pattern.

The proxy pattern according to GoF has the intent of providing a placeholder object (with the same interface), in order to control access to the original object.

So if you have no special need, there is no advantage for this pattern.

However, there are a couple of scenarios where proxies are really useful. For example:

• if your objects are managed on a remote server, you could have a local proxy that forwards the operations via a network interface to the remote object.
• if your objects are resource consuming and you have them most of their time stored on disk, you can use the proxy to act as placeholder. The proxy would then deserialize the object when it's needed and forward it the operations (e.g. cache).
• if you want to add access control, for example make sure that an object is accessed read-only (by replacing any changing operations by a stub) or making user-based access control before really doing the operations (e.g. if the user is authorised, do the operation, if not, throw an access control exception. with the advantage of separation of concerns between the object's behaviour and the access control)