Programmering

Arbejde med adapterens designmønster

Designmønstre er løsninger på tilbagevendende problemer og kompleksitet i softwaredesign. Designmønstre er kategoriseret som skabelsesmæssige, strukturelle eller adfærdsmæssige. Skabelsesmønstre bruges til at oprette og styre mekanismen til oprettelse af forekomster af klasser. Strukturelle mønstre bruges til at realisere forholdet mellem enhederne. Adfærdsmæssige designmønstre beskæftiger sig med objektsamarbejde og delegering af ansvar.

Adaptermønsteret er et strukturelt designmønster, der fungerer som en bro mellem to grænseflader, der er inkompatible. Udtrykket "adapter" bruges til at repræsentere et objekt, der gør det muligt for to indbyrdes uforenelige grænseflader at kommunikere og samarbejde. Kort sagt gør adaptermønsteret det muligt for klasser (der har uforenelige grænseflader) at arbejde sammen, og deres objekter kommunikerer, hvis det er nødvendigt.

Der er visse typer adaptere, der implementerer grænsefladerne til både målet og adapteren. Sådanne typer adaptere er kendt som tovejs-adaptere. Du har også to forskellige typer adaptere, nemlig klasse adaptere og objekt adaptere. Mens førstnævnte bruger arv, bruger sidstnævnte sammensætning til at løse problemer med inkompatibilitet i dine designs. Du kan bruge adapterens designmønster, når du har brug for et tredjepartsbibliotek, der er uforeneligt med de typer, du har i din applikation.

Følgende er listen over de typer, der deltager i en typisk implementering af adaptermønsteret:

  • Mål
  • Adapter
  • Tilpasset
  • Klient

Lad os forstå dette med et eksempel. Antag, at to personer, der taler og forstår forskellige sprog, har brug for at kommunikere - den ene kan være fransk og den anden tysk. Så disse to personer kan kun tale og forstå henholdsvis fransk og tysk - ikke begge. Du har typisk brug for nogen (en tolk), der kender begge disse sprog for at lette kommunikationen. Så den person, der kan lette denne kommunikation, fungerer som adapter.

Dette mønster falder ind under den strukturelle kategori, da du ville bruge dette mønster til at strukturere typerne i vores applikation - typisk kan dette mønster omdanne en grænseflade til en anden. Gang of Four definerer adaptermønsteret som "Konverter grænsefladen til en klasse til en anden grænseflade, som klienterne forventer. Adapter lader klasser arbejde sammen, der ellers ikke kunne på grund af inkompatible grænseflader."

Lad os grave i noget kode nu. Overvej 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 klasser uforenelige - de har heller ikke nogen fælles base. Følgende kodeliste viser, hvordan adapterklasser ser ud.

offentlig grænseflade ITargetAdapter

            {

ugyldige ProcessData ();

            }

offentlig klasse AdapterA: ITargetAdapter

            {

offentlig TargetA targetA {get; sæt; }

offentlig ugyldig proces ()

                 {

targetA.DisplayA ();

                 }

offentlig AdapterA (TargetA obj)

                 {

targetA = obj;

                 }

            }

offentlig klasse AdapterB: ITargetAdapter

            {

offentlig TargetB targetB {get; sæt; }

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

offentlig AdapterB (TargetB obj)

                 {

targetB = obj;

                 }

            }

Bemærk, at begge adapterklasser har en fælles grænseflade med navnet ITargetAdapter, som disse klasser implementerer. Hver af de to adapterklasser har en argumentkonstruktør, der accepterer en henvisning til et objekt fra de respektive målklasser. ITargetAdapter-grænsefladen indeholder erklæringen om Process () -metoden. Denne metode implementeres af begge adapterklasser - disse metoder påberåber Display () og de respektive displaymetoder for de målklasser, vi implementerede tidligere.

Følgende kodeliste illustrerer, hvordan du kan bruge disse adapterklasser.

klasse Program

    {

statisk ugyldigt Main (streng [] args)

        {

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

adapter.Proces ();

adapter = ny AdapterB (ny TargetB ());

adapter.Proces ();

Console.Read ();

        }

Som du kan se i ovenstående kodestykke, skal vi sende en forekomst af den respektive målklasse til konstruktøren af ​​adapterklassen.

Jeg præsenterer diskussioner om flere designmønstre i mine kommende indlæg her. Adapterdesignmønsteret kan være et godt valg, når du har brug for at påberåbe ældre kode i dine applikationer. Du kan lære mere om adapterdesignmønsteret i denne artikel.

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