Programmering

Arbeider med adapterdesignmønsteret

Designmønstre er løsninger på gjentatte problemer og kompleksitet i programvaredesign. Designmønstre er kategorisert som Creational, Structural, eller Behavioral. Skapelsesmønstre brukes til å lage og administrere mekanismen for å skape forekomster av klasser. Strukturelle mønstre brukes til å realisere forholdet mellom enhetene. Atferdsmønstre håndterer objektsamarbeid og delegering av ansvar.

Adaptermønsteret er et strukturelt designmønster som fungerer som en bro mellom to grensesnitt som er inkompatible. Begrepet "Adapter" brukes til å representere et objekt som gjør det mulig for to gjensidig uforenlige grensesnitt å kommunisere og samarbeide. I hovedsak gjør adaptermønsteret det mulig for klasser (som har inkompatible grensesnitt) å jobbe sammen, og objektene deres kommuniserer om nødvendig.

Det er visse typer adaptere som implementerer grensesnitt for både Target og Adaptee. Slike typer adaptere er kjent som toveis adaptere. Du har også to forskjellige typer adaptere, nemlig klasseadaptere og objektadaptere. Mens førstnevnte bruker arv, bruker sistnevnte komposisjon for å løse problemer med inkompatibilitet i designene dine. Du kan bruke adapterdesignmønsteret når du trenger å bruke et tredjepartsbibliotek som er inkompatibelt med typene du har i applikasjonen din.

Følgende er listen over typene som deltar i en typisk implementering av adaptermønsteret:

  • Mål
  • Adapter
  • Tilpasset
  • Klient

La oss forstå dette med et eksempel. Anta at to personer som snakker og forstår forskjellige språk, må kommunisere - den ene kan være fransk og den andre tysk. Så disse to personene kan bare snakke og forstå henholdsvis fransk og tysk - ikke begge. Du trenger vanligvis noen (en tolk) som kan begge disse språkene for å lette kommunikasjonen. Så personen som kan legge til rette for denne kommunikasjonen fungerer som adapter.

Dette mønsteret faller inn under strukturell kategori siden du vil bruke dette mønsteret til å strukturere typene i applikasjonen vår - vanligvis kan dette mønsteret forvandle ett grensesnitt til et annet. Gang of Four definerer adaptermønsteret som "Konverter grensesnittet til en klasse til et annet grensesnitt som klientene forventer. Adapter lar klasser samarbeide som ellers ikke kunne på grunn av inkompatible grensesnitt."

La oss grave i litt kode nå. Tenk på følgende to klasser.

offentlig klasse TargetA

            {

offentlig ugyldig DisplayA ()

                {

Console.WriteLine ("TargetA");

                }

            }

offentlig klasse TargetB

            {

offentlig ugyldig DisplayB ()

                {

Console.WriteLine ("TargetB");

                }

            }

Som du kan se er de to klassene inkompatible - de har heller ikke noen felles base. Følgende kodeliste viser hvordan adapterklassene ser ut.

offentlig grensesnitt ITargetAdapter

            {

ugyldig ProcessData ();

            }

offentlig klasse AdapterA: ITargetAdapter

            {

offentlig TargetA targetA {get; sett; }

offentlig ugyldig prosess ()

                 {

targetA.DisplayA ();

                 }

offentlig AdapterA (TargetA obj)

                 {

targetA = obj;

                 }

            }

offentlig klasse AdapterB: ITargetAdapter

            {

offentlig TargetB targetB {get; sett; }

offentlig ugyldig prosess () {targetB.DisplayB (); }

public AdapterB (TargetB obj)

                 {

målB = obj;

                 }

            }

Merk at begge adapterklassene har ett felles grensesnitt kalt ITargetAdapter som disse klassene implementerer. Hver av de to adapterklassene har en argumentkonstruktør som godtar en referanse til et objekt fra de respektive målklassene. ITargetAdapter-grensesnittet inneholder erklæringen om prosessen () -metoden. Denne metoden er implementert av begge adapterklassene - disse metodene påkaller Display () og de respektive displaymetodene for målklassene vi implementerte tidligere.

Følgende kodeliste illustrerer hvordan du kan bruke disse adapterklassene.

klasse Program

    {

statisk tomrom Main (streng [] args)

        {

ITargetAdapter adapter = ny AdapterA (ny TargetA ());

adapter.Prosess ();

adapter = ny AdapterB (ny TargetB ());

adapter.Prosess ();

Console.Read ();

        }

Som du kan se i kodebiten ovenfor, må vi sende en forekomst av den respektive målklassen til konstruktøren av adapterklassen.

Jeg vil presentere diskusjoner om flere designmønstre i mine kommende innlegg her. Adapterdesignmønsteret kan være et godt valg når du trenger å påkalle eldre kode i applikasjonene dine. Du kan lære mer om adapterdesignmønsteret fra denne artikkelen.

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