Condivisione della tecnologia

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

modello strutturale

Modello proxy

Proxy Pattern è un modello di progettazione strutturale che controlla l'accesso a un altro oggetto introducendo un oggetto proxy. Questo oggetto proxy può fornire funzionalità aggiuntive all'oggetto proxy, ad esempio controllo dell'accesso, inizializzazione lenta, registrazione o accesso alla rete.

Scena applicabile

1. agente remoto：

   • Fornisce la rappresentazione locale di un oggetto in diversi spazi di indirizzi.

2. agente virtuale：

   • Crea oggetti costosi secondo necessità.

3. agente di protezione：

   • Controllare l'accesso all'oggetto originale.

4. Guida intelligente：

   • Eseguire alcune operazioni aggiuntive quando si accede all'oggetto, come operazioni di conteggio o rilevamento dei riferimenti.

Esempio di implementazione (Java)

Di seguito è riportato un semplice esempio di implementazione del modello proxy, che mostra come controllare l'accesso a un oggetto reale tramite un oggetto proxy.

1. Definire l'interfaccia del tema

public interface Subject {
    void request();
}
1
2
3

• illustrare：Subject L'interfaccia definisce arequest Metodo, questo è il metodo che sia l'oggetto reale che l'oggetto proxy devono implementare.

2. Definire la classe del soggetto reale (RealSubject)

public class RealSubject implements Subject {
    public void request() {
        System.out.println("RealSubject: Handling request.");
    }
}
1
2
3
4
5

• illustrare：RealSubject classe implementataSubject Interfacciarequest Metodo, che rappresenta la classe che gestisce effettivamente la richiesta.

3. Definire la classe proxy (Proxy)

public class Proxy implements Subject {
    private RealSubject realSubject;

    public Proxy(RealSubject realSubject) {
        this.realSubject = realSubject;
    }

    public void request() {
        if (this.checkAccess()) {
            this.realSubject.request();
            this.logAccess();
        }
    }

    private boolean checkAccess() {
        // 检查访问权限
        System.out.println("Proxy: Checking access prior to firing a real request.");
        return true;
    }

    private void logAccess() {
        // 记录请求日志
        System.out.println("Proxy: Logging the time of request.");
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

• illustrare：
  • Proxy classe implementataSubject interfaccia e contiene aRealSubject oggetto.
  • esistere request Nel metodo, la classe proxy controlla prima i permessi di accesso e poi chiama l'oggetto realerequest metodo e infine registrare il registro della richiesta.

4. Codice cliente

public class Client {
    public static void main(String[] args) {
        RealSubject realSubject = new RealSubject();
        Proxy proxy = new Proxy(realSubject);
        
        proxy.request();
    }
}
1
2
3
4
5
6
7
8

• illustrare：
  • Client classe creataRealSubject EProxy oggetto, attraversoProxy Chiamata oggettorequest metodo per controllare ilRealSubject Accesso.

vantaggio

1. Isolamento：

   • La modalità proxy può fungere da intermediario tra il chiamante e l'oggetto reale, riducendo l'accoppiamento tra i componenti del sistema e migliorando l'isolamento tra gli oggetti.

2. sicurezza：

   • L'accesso agli oggetti reali può essere controllato tramite proxy, consentendo controlli di sicurezza e verifiche approfondite.

3. Scalabilità：

   • La modalità proxy può aggiungere in modo flessibile funzioni senza modificare il codice oggetto specifico.

4. Intelligente：

   • Alcune operazioni aggiuntive, come l'inizializzazione ritardata e i log di accesso, possono essere implementate senza modificare l'interfaccia dell'oggetto servizio.

discordanza

1. complessità del codice：

   • Introdurre gli agenti significa anche aumentare la complessità del sistema, eventualmente introducendo nuove classi e interfacce, e aumentare la comprensione del codice e i costi di manutenzione.

2. Tempo di risposta：

   • La modalità proxy può rallentare l'esecuzione del sistema, soprattutto se all'operazione proxy viene aggiunta molta logica di elaborazione.

3. Difficoltà di progettazione：

   • La corretta progettazione e implementazione del modello proxy richiede un'attenta considerazione della progettazione complessiva del sistema per garantire che non vi sia alcun impatto negativo sulle prestazioni del sistema.

Diagramma delle classi

Client
  |
  v
Subject <---- Proxy <---- RealSubject
1
2
3
4

Riassumere

Il modello proxy fornisce un modo efficiente per controllare e gestire l'accesso agli oggetti. Utilizzando i proxy, è possibile aggiungere varie funzioni mantenendo chiare le responsabilità degli oggetti business. Questa modalità è particolarmente adatta per scenari che richiedono il controllo degli accessi e altre operazioni di preelaborazione sugli oggetti business.

Modello di facciata

Facade Pattern è un modello di progettazione strutturale che semplifica l'utilizzo di sottosistemi complessi fornendo un'interfaccia unificata per l'accesso a un gruppo di interfacce nel sottosistema. Il modello della facciata definisce un'interfaccia di alto livello che rende questo sottosistema più facile da usare.

Scena applicabile

1. Semplificare le interfacce per sistemi complessi：

   • Fornire un'interfaccia semplice per sottosistemi complessi per ridurre la complessità delle interazioni esterne con i sottosistemi.

2. Gerarchia：

   • In una struttura di sistema multistrato, i modelli di aspetto possono essere utilizzati per definire l'ingresso in ogni strato e semplificare le dipendenze tra gli strati.

3. Sistema disaccoppiato：

   • Introducendo il modello di aspetto, l'accoppiamento tra il sottosistema e il client viene ridotto.

Esempio di implementazione (Java)

Quello che segue è un semplice esempio di implementazione del modello Facade, che mostra come semplificare l'uso dei sottosistemi attraverso le classi di facciata.

1. Definire le classi del sottosistema

public class SubsystemA {
    public void operationA() {
        System.out.println("SubsystemA: operationA");
    }
}

public class SubsystemB {
    public void operationB() {
        System.out.println("SubsystemB: operationB");
    }
}

public class SubsystemC {
    public void operationC() {
        System.out.println("SubsystemC: operationC");
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

2. Definire la classe di aspetto

public class Facade {
    private SubsystemA subsystemA;
    private SubsystemB subsystemB;
    private SubsystemC subsystemC;

    public Facade() {
        this.subsystemA = new SubsystemA();
        this.subsystemB = new SubsystemB();
        this.subsystemC = new SubsystemC();
    }

    public void operation1() {
        System.out.println("Facade: operation1");
        subsystemA.operationA();
        subsystemB.operationB();
    }

    public void operation2() {
        System.out.println("Facade: operation2");
        subsystemB.operationB();
        subsystemC.operationC();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

3. Codice cliente

public class Client {
    public static void main(String[] args) {
        Facade facade = new Facade();
        facade.operation1();
        facade.operation2();
    }
}
1
2
3
4
5
6
7

Appunti

1. Classe del sottosistema：

   • SubsystemA, SubsystemB, E SubsystemC È la classe di implementazione specifica del sottosistema e ciascuna classe ha il proprio metodo operativo univoco.

2. Classe di aspetto：

   • Facade Le classi contengono oggetti del sottosistema e forniscono interfacce semplificateoperation1 Eoperation2 per chiamare le funzioni del sottosistema.

3. codice cliente：

   • Client lezione superataFacade lezione da chiamareoperation1 Eoperation2, semplificando così l'utilizzo di sottosistemi complessi.

vantaggio

1. Interfaccia semplificata：

   • Il modello di aspetto fornisce un'interfaccia semplice per i sottosistemi, riducendo la complessità dell'interazione con i sottosistemi.

2. accoppiamento lasco：

   • Il modello di aspetto riduce l'accoppiamento tra il sottosistema e il client, il che aiuta a migliorare la manutenibilità e la scalabilità del sistema.

3. migliore stratificazione：

   • I modelli di aspetto aiutano a stabilire una struttura gerarchica chiara, definendo l'ingresso a ciascun livello.

discordanza

1. Non rispetta il principio apri-chiudi：

   • Quando si aggiungono nuove funzioni del sottosistema, potrebbe essere necessario modificare la classe di aspetto, che viola il principio aperto-chiuso (aperto per estensioni, chiuso per modifiche).

2. Potrebbe causare problemi di prestazioni：

   • In alcuni casi, l'utilizzo del modello di facciata può causare un degrado delle prestazioni del sistema poiché tutte le richieste devono passare attraverso la classe di facciata.

Diagramma delle classi

Client
  |
  v
Facade ----> SubsystemA
          ----> SubsystemB
          ----> SubsystemC
1
2
3
4
5
6

Riassumere

Il modello Facade semplifica il lavoro con sottosistemi complessi fornendo un'interfaccia semplificata. È adatto per scenari in cui è necessario semplificare l'interfaccia del sottosistema, ridurre l'interazione diretta tra il client e il sottosistema e disaccoppiare la gerarchia del sistema. Sebbene possa potenzialmente violare il principio aperto-chiuso, nella maggior parte dei casi i suoi vantaggi superano di gran lunga gli svantaggi, rendendo la progettazione del sistema più chiara e più facile da mantenere.