Hva er designmønstre: hvorfor bruke dem, klassifisering, fordeler og ulemper

I programvareteknikk er designmønstre optimale løsninger på problemer som ofte oppstår i programvaredesign.

De er som forprosjekterdefinett, utprøvde verktøy som du kan tilpasse for å løse et tilbakevendende designproblem i koden din.

Beregnet lesetid: 6 minutter

Hva er et designmønster

Et designmønster er ikke kode som vi kan kopiere og sette inn i programmet vårt, slik vi kan gjøre med standardfunksjoner eller biblioteker. Designmønsteret er et generelt konsept som er i stand til å løse et bestemt problem. I utgangspunktet en modell hvis detaljer vi kan følge og implementere en løsning som passer til virkeligheten til programmet vårt.

Modeller forveksles ofte med algoritmer, fordi begge konseptene beskriver typiske løsninger på noen kjente problemer. Mens en algoritme defiHvis det alltid er et klart sett med handlinger som kan oppnå et bestemt mål, er en modell en beskrivelse av en løsning på høyere nivå. Kode fra samme modell brukt på to forskjellige programmer kan være forskjellig.

For å lage en analogi, kan vi tenke på en matlagingsoppskrift: begge har klare trinn for å oppnå et mål. Imidlertid er en modell mer som et prosjekt, hvor du kan se hva resultatet og dets egenskaper er, men den nøyaktige rekkefølgen for implementering avhenger av oss som skriver koden.

Hva er et designmønster laget av?

De fleste mønstre er beskrevet veldig formelt slik at folk kan gjengi dem i mange sammenhenger. La oss se nedenfor elementene som er til stede i beskrivelsen av en modell:

• Hensikten av modellen beskriver kort både problemet og løsningen.
• Motivasjonen forklarer videre problemet og løsningen som modellen muliggjør.
• Struktur av klasser viser hver del av modellen og hvordan de henger sammen.
• Kodeeksemplet på et av de mest populære programmeringsspråkene gjør det lettere å forstå ideen bak modellen.

Hvorfor bruke dem?

En programmerer kan utvikle programvare uten å vite eksistensen av designmønstre. Mange gjør det, og av denne grunn implementerer de noen ordninger uten å vite det. Men hvorfor skal vi bruke tid på å lære dem?

• Designmønstrene er et sett med utprøvde løsninger til vanlige problemer innen programvaredesign. Selv om du aldri støter på disse problemene, er det fortsatt nyttig å kjenne mønstre fordi det lærer deg hvordan du løser alle slags problemer ved å bruke objektorienterte designprinsipper.
• Designmodellene defiDe skaper et felles språk som du og teamet ditt kan bruke for å kommunisere mer effektivt. Du kan si, "Å, bare bruk en Singleton til å gjøre dette," og alle vil forstå ideen bak forslaget ditt. Det er ikke nødvendig å forklare hva en singleton er hvis du kjenner mønsteret og navnet.

Klassifisering av designmønstre

Designmønstre varierer i kompleksitet, detaljnivå og omfang av anvendelighet gjennom hele designet.

I analogi kan vi gjøre et veikryss tryggere ved å installere noen få trafikklys eller bygge en hel flerplansveksling med underjordiske passasjer for fotgjengere.

De mest grunnleggende modellene på lavt nivå kalles ofte idiomer . De gjelder vanligvis bare for ett enkelt programmeringsspråk.

De mest universelle og høynivåmodellene er arkitektoniske modeller . Utviklere kan implementere disse mønstrene på praktisk talt alle språk. I motsetning til andre mønstre, kan de brukes til å designe arkitekturen til en hel applikasjon.

Videre kan alle modeller klassifiseres etter deres prøvde eller formål. De tre hovedklassene er:

• Kreasjonelle modeller de gir objektskapingsmekanismer som øker fleksibiliteten og gjenbruk av eksisterende kode.
• Strukturelle modeller de forklarer hvordan man setter sammen objekter og klasser til større strukturer, og holder disse strukturene fleksible og effektive.
• Atferdsmodeller de omhandler effektiv kommunikasjon og tildeling av ansvar mellom objekter.

Eksempel på designmønster i Laravel: Fasade

fasade er et strukturelt designmønster som gir et forenklet grensesnitt til et bibliotek, rammeverk eller et hvilket som helst annet komplekst sett med klasser.

Problem

La oss anta at vi må få programvare til å fungere, basert på et stort sett med objekter som tilhører et sofistikert bibliotek eller rammeverk. Normalt vil vi måtte initialisere alle disse objektene, holde styr på avhengigheter, utføre metoder i riktig rekkefølge, og så videre.

Som et resultat ville forretningslogikken til klassene bli tett koblet til implementeringsdetaljene til tredjepartsklasser, noe som gjør dem vanskelige å forstå og administrere.

Løsning

en facade er en klasse som gir et enkelt grensesnitt til et komplekst delsystem som inneholder mange bevegelige deler. EN facade kan gi begrenset funksjonalitet sammenlignet med å jobbe direkte med delsystemet. Den inkluderer imidlertid bare funksjonene som kundene virkelig bryr seg om.

Ha en facade det er nyttig når vi trenger å integrere appen med et sofistikert bibliotek som har dusinvis av funksjoner, men vi trenger bare en liten del av funksjonaliteten.

For eksempel kan en app som laster opp korte morsomme videoer med katter til sosiale medier potensielt bruke et profesjonelt videokonverteringsbibliotek. Men alt vi egentlig trenger er en klasse med enkeltmetoden encode(filename, format). Etter å ha opprettet en slik klasse og koblet den til videokonverteringsbiblioteket, vil vi ha vår første facade.

For eksempel er telefonoperatøren til et kundesenter som en facade. Faktisk, når vi ringer en butikks telefontjeneste for å legge inn en telefonbestilling, er en operatør vår facade mot alle tjenester og avdelinger i butikken. Operatøren gir et enkelt talegrensesnitt til bestillingssystemet, betalingsgatewayer og ulike leveringstjenester.

Ekte eksempel i PHP

Tenk om fasade som en enkel adapter for noen komplekse delsystemer. Facade isolerer kompleksiteten i en enkelt klasse og lar annen applikasjonskode bruke det enkle grensesnittet.

I dette eksemplet, Facade skjuler kompleksiteten til YouTube API og FFmpeg-biblioteket fra klientkoden. I stedet for å jobbe med dusinvis av klasser, bruker klienten en enkel metode på Fasade.

<?php

namespace RefactoringGuru\Facade\RealWorld;

/**
 * The Facade provides a single method for downloading videos from YouTube. This
 * method hides all the complexity of the PHP network layer, YouTube API and the
 * video conversion library (FFmpeg).
 */
class YouTubeDownloader
{
    protected $youtube;
    protected $ffmpeg;

    /**
     * It is handy when the Facade can manage the lifecycle of the subsystem it
     * uses.
     */
    public function __construct(string $youtubeApiKey)
    {
        $this->youtube = new YouTube($youtubeApiKey);
        $this->ffmpeg = new FFMpeg();
    }

    /**
     * The Facade provides a simple method for downloading video and encoding it
     * to a target format (for the sake of simplicity, the real-world code is
     * commented-out).
     */
    public function downloadVideo(string $url): void
    {
        echo "Fetching video metadata from youtube...\n";
        // $title = $this->youtube->fetchVideo($url)->getTitle();
        echo "Saving video file to a temporary file...\n";
        // $this->youtube->saveAs($url, "video.mpg");

        echo "Processing source video...\n";
        // $video = $this->ffmpeg->open('video.mpg');
        echo "Normalizing and resizing the video to smaller dimensions...\n";
        // $video
        //     ->filters()
        //     ->resize(new FFMpeg\Coordinate\Dimension(320, 240))
        //     ->synchronize();
        echo "Capturing preview image...\n";
        // $video
        //     ->frame(FFMpeg\Coordinate\TimeCode::fromSeconds(10))
        //     ->save($title . 'frame.jpg');
        echo "Saving video in target formats...\n";
        // $video
        //     ->save(new FFMpeg\Format\Video\X264(), $title . '.mp4')
        //     ->save(new FFMpeg\Format\Video\WMV(), $title . '.wmv')
        //     ->save(new FFMpeg\Format\Video\WebM(), $title . '.webm');
        echo "Done!\n";
    }
}

/**
 * The YouTube API subsystem.
 */
class YouTube
{
    public function fetchVideo(): string { /* ... */ }

    public function saveAs(string $path): void { /* ... */ }

    // ...more methods and classes...
}

/**
 * The FFmpeg subsystem (a complex video/audio conversion library).
 */
class FFMpeg
{
    public static function create(): FFMpeg { /* ... */ }

    public function open(string $video): void { /* ... */ }

    // ...more methods and classes... RU: ...дополнительные методы и классы...
}

class FFMpegVideo
{
    public function filters(): self { /* ... */ }

    public function resize(): self { /* ... */ }

    public function synchronize(): self { /* ... */ }

    public function frame(): self { /* ... */ }

    public function save(string $path): self { /* ... */ }

    // ...more methods and classes... RU: ...дополнительные методы и классы...
}


/**
 * The client code does not depend on any subsystem's classes. Any changes
 * inside the subsystem's code won't affect the client code. You will only need
 * to update the Facade.
 */
function clientCode(YouTubeDownloader $facade)
{
    // ...

    $facade->downloadVideo("https://www.youtube.com/watch?v=QH2-TGUlwu4");

    // ...
}

$facade = new YouTubeDownloader("APIKEY-XXXXXXXXX");
clientCode($facade);

Ercole Palmeri