Хорошо, я боролся с некоторым кодом, основанным на API, который, кажется, использует много Proxy Pattern. Оказывается, API написан так, чтобы он мог перехватывать некоторые входящие вызовы к набору интерфейсов: если вызывающие объекты имеют правильное состояние, они могут вызвать «большой» объект в памяти. Кроме того, возможно, это могло бы быть полезно в многопоточном сценарии, но я думаю, что могу ошибаться здесь: синхронизация не должна быть внешним волшебным порошком, который нужно посыпать поверх существующих классов, которые не ожидали этого при написании. Больше всего меня раздражает то, что эти 'Proxy Components' разделяют те же самые интерфейсы, что и сами объекты. Это вызывает огромный беспорядок при написании кода с их использованием, потому что тогда вы никогда не будете уверены, что сбой мог быть вызван какой-либо другой причиной, за исключением общего неверного случая параметра / состояния. Это противоречит 'happy-path', early-return, и обычно создает больше путаницы в дальнейшей логике. Как приступить к написанию кода с использованием этого шаблона? Как это хороший образец? Каковы некоторые из хороших сценариев, когда Proxy Pattern следует и нельзя использовать?
![Мотивация использования шаблона прокси [closed] TheFAQ.ru](https://thefaq.ru/wp-content/uploads/2023/01/logo-250.png)