Quali sono i vantaggi delle classi proxy?

Note preliminari importanti

Prima di tutto, non dovresti scegliere un modello di design in un catalogo, perché è alla moda o considerando vantaggi e inconvenienti. Dovresti scegliere un modello di design se corrisponde a un problema che hai e si adatta al tuo design.

Inoltre, i pattern non hanno una sola definizione di frase. I pattern sono definiti da una combinazione di un intento (qual è lo scopo) e una descrizione della loro struttura (come lo scopo è soddisfatto).

Il proxy

Detto questo, ciò che descrivi è uno schema che mira a cambiare l'interfaccia di un oggetto. Questo sarebbe piuttosto qualcosa di simile ad un adattatore (anche se non è una corrispondenza ravvicinata qui neanche).

Alcuni altri post nella domanda collegata suggeriscono di usare il pattern proxy per aggiungere operatori. Ma aggiungere nuove responsabilità è l'obiettivo del modello di decoratore.

Il modello proxy secondo GoF ha lo scopo di fornire un oggetto segnaposto (con la stessa interfaccia), per controllare l'accesso all'oggetto originale.

Quindi, se non hai esigenze particolari, non c'è alcun vantaggio per questo modello.

Tuttavia, ci sono un paio di scenari in cui i proxy sono davvero utili. Ad esempio:

• se i tuoi oggetti sono gestiti su un server remoto, potresti avere un proxy locale che inoltra le operazioni tramite un'interfaccia di rete all'oggetto remoto.
• se i tuoi oggetti consumano risorse e hai la maggior parte del loro tempo memorizzato su disco, puoi usare il proxy per fungere da segnaposto. Il proxy deserializza quindi l'oggetto quando è necessario e inoltra le operazioni (ad es. Cache).
• se si desidera aggiungere il controllo dell'accesso, ad esempio, assicurarsi che l'accesso a un oggetto sia di sola lettura (sostituendo qualsiasi operazione di modifica da parte di uno stub) o effettuare il controllo degli accessi basato sugli utenti prima di eseguire realmente le operazioni (ad es. se l'utente è autorizzato, fare l'operazione, in caso contrario, lanciare un'eccezione di controllo degli accessi con il vantaggio della separazione delle preoccupazioni tra il comportamento dell'oggetto e il controllo di accesso)

Una nota sulla terminologia:

Ciò di cui stai parlando non è chiamato proxy. Il nome più comune utilizzato è "pImpl", essendo un accorciamento di "Puntatore all'implementazione". È un modello particolare del modello di compilazione C ++.

Il motivo per cui utilizzerai pImpl è di mantenere la compatibilità binaria con i tuoi utenti delle classi, anche in caso di modifica dell'implementazione.

Come schizzo

foo.h:

class FooImpl; // Forward declaration, FooImpl is incomplete

class Foo {
public:
    ~Foo(); // Need to specify destructor, as the default is ill formed due to the incompleteness of FooImpl
    void bar(int);
    // etc
private:
    std::unique_ptr<FooImpl> pImpl;
};

FooUser.cpp

#include <Foo.h>

void DoStuff()
{
    Foo foo;
    foo.bar(0);
}

Foo.cpp

#include <Foo.h>
#include <Bar.h>
#include <Baz.h>
#include <Quux.h>

class FooImpl
{
    Bar bar;
    Baz baz;
    Quux quux;
    void do_bar(int) {}
};

Foo::~Foo() {} // Now we have the complete definition of FooImpl, this is well formed

void Foo::bar(int i) { pImpl->do_bar(i); }

FooUser.cpp è completamente isolato dall'implementazione di Foo . In particolare, nessun #include s che Foo deve definire per i suoi membri è visibile a FooUser.cpp . Qualsiasi modifica a Foo.cpp non forza FooUser.cpp da ricompilare.