В паттерне Proxy применяется виртуальный класс Interface, можно обойтись и без него.
Код с Interface классом

class Subject {//"Interface"
 public:
    virtual void request() = 0;
};

class RealSubject: public Subject {//"Real Interface"
 public:
    virtual void request()    {
        // Do something.
    };
};
class Proxy: public Subject {
 private:
    RealSubject* subject;
 public:
    virtual void request()    {
        subject -> request();
    };
    RealSubject* getSubject()    {
        return subject;
    };
    void setSubject( RealSubject* subject )    {
        this -> subject = subject;
    };
};

void main() {
 RealSubject* subject = new RealSubject();
 Proxy* proxy = new Proxy();

 proxy -> setSubject( subject );// Configure the proxy.
 proxy -> request();// Use the proxy to access the subject.

 //Clean-up.
 delete proxy;
 delete subject;
}

Код без Interface класса

class RealSubject{//"Real Interface"
 public:
    virtual void request()    {
        // Do something.
    };
};
class Proxy {//"Proxy"
 private:
    RealSubject* subject;
 public:
     Proxy(){subject=0;}
     ~Proxy(){
         delete subject; }
    virtual void request()    {
        if(!subject)
            subject=new RealSubject;
        subject->request();
    };
};

void main() {
 Proxy* proxy = new Proxy();
 proxy -> request();//создали объект
 proxy -> request();//работаем с уже созданным
 //Clean-up.
 delete proxy;

}

Для чего его ввели, что он даёт дополнительно полезного?
Аналогично паттерн Decorator вроде можно реализовать без него.(возможно и Composite)
Нужен ли этот класс или лучше написать более кратко без него?

Здравствуйте, PWW, Вы писали:

PWW>Для чего его ввели, что он даёт дополнительно полезного?

Гарантирует соответствие интерфейсов RealSubject и Proxy.

Здравствуйте, PWW, Вы писали:


PWW>Для чего его ввели, что он даёт дополнительно полезного?

вот для чего (на утечки не обращать внимания).

RealSubject1* subject1 = new RealSubject1();
RealSubject2* subject2 = new RealSubject2();
Proxy* proxy = new Proxy();

proxy -> setSubject( subject1 );
proxy -> request();

proxy -> setSubject( subject2 );
proxy -> request();

Здравствуйте, Аноним, Вы писали:

PWW>>Для чего его ввели, что он даёт дополнительно полезного?
А>вот для чего (на утечки не обращать внимания).

А>

А>RealSubject1* subject1 = new RealSubject1();
А>RealSubject2* subject2 = new RealSubject2();
А>Proxy* proxy = new Proxy();

А>proxy -> setSubject( subject1 );
А>proxy -> request();

А>proxy -> setSubject( subject2 );
А>proxy -> request();
А>

Этот код будет работать и с вышеописанным вторым вариантом без интерфейса, если в класс Proxy вернуть функцию setSubject...

Вместо прокси может быть исользован и сам объект. Если нет, то действительно можно без интерфейса.

Декоратор — добавления чего-то в объект, при том что результат предоставляет тот же интерфейс и используется там же. Тут в том и смысл что получается внешне тот же объект
У композита в том и смысл что одинаковая работа с составными и с простыми объектами.

Интерфейсы и их реализации не обязательно через виртуальные функции, можно и на статическом полиморфизме через темплейты реализовать эти паттерны.

Здравствуйте, _Jane_, Вы писали:
PWW>>Для чего его ввели, что он даёт дополнительно полезного?
_J_>Гарантирует соответствие интерфейсов RealSubject и Proxy.

Похоже это и есть наиболее правильный ответ, застсвить соблюдать
одинаковые названия функций:

RealSubject::request() <==> Proxy::request()
а не
RealSubject::request() <==> Proxy::request2()