Proxy-mønsteret i Java

1. Oversikt

Proxy-mønsteret lar oss lage en mellommann som fungerer som et grensesnitt til en annen ressurs, samtidig som den skjuler den underliggende kompleksiteten til komponenten.

2. Eksempel på proxy-mønster

Vurder et tungt Java-objekt (som en JDBC-forbindelse eller en SessionFactory) som krever noen innledende konfigurasjoner.

Vi vil bare at slike gjenstander skal initialiseres på forespørsel, og når de er det, vil vi bruke dem til alle samtaler:

La oss nå lage et enkelt grensesnitt og konfigurasjonen for dette objektet:

offentlig grensesnitt ExpensiveObject {ugyldig prosess (); }

Og implementeringen av dette grensesnittet med en stor innledende konfigurasjon:

offentlig klasse ExpensiveObjectImpl implementerer ExpensiveObject {public ExpensiveObjectImpl () {heavyInitialConfiguration (); } @ Overstyr offentlig ugyldig prosess () {LOG.info ("behandlingen fullført."); } privat ugyldig heavyInitialConfiguration () {LOG.info ("Laster innledende konfigurasjon ..."); }}

Vi bruker nå proxy-mønsteret og initialiserer objektet vårt på forespørsel:

offentlig klasse ExpensiveObjectProxy implementerer ExpensiveObject {privat statisk ExpensiveObject-objekt; @ Overstyr offentlig ugyldig prosess () {if (object == null) {object = new ExpensiveObjectImpl (); } object.process (); }}

Når vår klient ringer prosess() metode, vil de bare se behandlingen og den opprinnelige konfigurasjonen vil alltid forbli skjult:

public static void main (String [] args) {ExpensiveObject object = new ExpensiveObjectProxy (); object.process (); object.process (); }

Merk at vi ringer til prosess() metoden to ganger. Bak kulissene vil innstillingsdelen bare forekomme en gang - når objektet først initialiseres.

For hver annen påfølgende samtale hopper dette mønsteret over den opprinnelige konfigurasjonen, og bare behandlingen vil skje:

Laster inn den første konfigurasjonen ... behandlingen er fullført. behandlingen fullført.

3. Når skal du bruke proxy?

Forstå hvordan å bruke et mønster er viktig.

Forstå når å bruke det er kritisk.

La oss snakke om når vi skal bruke proxy-mønsteret:

  • Når vi ønsker en forenklet versjon av en kompleks eller tung gjenstand. I dette tilfellet kan vi representere det med et skjelettobjekt som laster originalobjektet på forespørsel, også kalt som lat initialisering. Dette er kjent som Virtual Proxy
  • Når det opprinnelige objektet er til stede i et annet adresserom, og vi vil representere det lokalt. Vi kan opprette en proxy som gjør alle nødvendige kjeleplater som å opprette og vedlikeholde tilkoblingen, koding, dekoding, etc., mens klienten får tilgang til den slik den var til stede i deres lokale adresserom. Dette kalles Remote Proxy
  • Når vi vil legge til et sikkerhetslag til det opprinnelige underliggende objektet for å gi kontrollert tilgang basert på klientens tilgangsrettigheter. Dette kalles Protection Proxy

4. Konklusjon

I denne artikkelen så vi på proxy-designmønsteret. Dette er et godt valg i følgende tilfeller:

  • Når vi vil ha en forenklet versjon av et objekt eller få tilgang til objektet sikrere
  • Når vi vil ha en lokal versjon av et eksternt objekt

Hele kildekoden for dette eksemplet er tilgjengelig på GitHub.


$config[zx-auto] not found$config[zx-overlay] not found