Hvad er designmønstre: hvorfor bruge dem, klassificering, fordele og ulemper

I software engineering er designmønstre optimale løsninger på problemer, der almindeligvis opstår i softwaredesign.

De er som forprojekterdefinite, afprøvede og testede værktøjer, som du kan tilpasse til at løse et tilbagevendende designproblem i din kode.

Estimeret læsetid: 6 minutter

Hvad er et designmønster

Et designmønster er ikke kode, som vi kan kopiere og indsætte i vores program, som vi kan gøre med standardfunktioner eller biblioteker. Designmønsteret er et generelt koncept, der er i stand til at løse et bestemt problem. Grundlæggende en model, hvis detaljer vi kan følge og implementere en løsning, der passer til virkeligheden af ​​vores program.

Modeller forveksles ofte med algoritmer, fordi begge begreber beskriver typiske løsninger på nogle kendte problemer. Mens en algoritme defiHvis der altid er et klart sæt af handlinger, der kan opnå et bestemt mål, er en model en beskrivelse af en løsning på et højere niveau. Kode fra samme model anvendt på to forskellige programmer kan være forskellig.

Hvis vi ønsker at lave en analogi, kan vi tænke på en madlavningsopskrift: begge har klare trin til at nå et mål. En model er dog mere som et projekt, hvor man kan se, hvad resultatet og dets karakteristika er, men den nøjagtige rækkefølge af implementering afhænger af os, der skriver koden.

Hvad er et designmønster lavet af?

De fleste mønstre er beskrevet meget formelt, så folk kan gengive dem i mange sammenhænge. Lad os nedenfor se de elementer, der er til stede i beskrivelsen af ​​en model:

• Hensigten af modellen beskriver kort både problemet og løsningen.
• Motivationen forklarer yderligere problemet og den løsning, som modellen muliggør.
• Struktur af klasser viser hver del af modellen, og hvordan de hænger sammen.
• Kodeeksemplet i et af de mest populære programmeringssprog gør det lettere at forstå ideen bag modellen.

Hvorfor bruge dem?

En programmør kan udvikle software uden at kende eksistensen af ​​designmønstre. Mange gør det, og af denne grund implementerer de nogle ordninger uden at vide det. Men hvorfor skulle vi så bruge tid på at lære dem?

• Designmønstrene er et sæt af afprøvede løsninger til almindelige problemer i softwaredesign. Selvom du aldrig støder på disse problemer, er det stadig nyttigt at kende mønstre, fordi det lærer dig, hvordan du løser alle slags problemer ved hjælp af objektorienterede designprincipper.
• Designmodellerne defiDe skaber et fælles sprog, som du og dit team kan bruge til at kommunikere mere effektivt. Du kan sige, "Åh, brug bare en Singleton til at gøre dette," og alle vil forstå ideen bag dit forslag. Der er ingen grund til at forklare, hvad en singleton er, hvis du kender mønsteret og dets navn.

Klassificering af designmønstre

Designmønstre adskiller sig i kompleksitet, detaljeringsgrad og anvendelighedsskala gennem hele det designede system.

I analogi kan vi gøre et vejkryds mere sikkert ved at installere et par lyskryds eller bygge en hel udveksling med flere niveauer med underjordiske passager til fodgængere.

De mest basale modeller på lavt niveau kaldes ofte idiomer . De gælder normalt kun for et enkelt programmeringssprog.

De mest universelle og højniveaumodeller er arkitektoniske modeller . Udviklere kan implementere disse mønstre på stort set alle sprog. I modsætning til andre mønstre kan de bruges til at designe arkitekturen for en hel applikation.

Desuden kan alle modeller klassificeres efter deres intentiono eller formål. De tre hovedklasser er:

• Kreative modeller de giver mekanismer til oprettelse af objekter, der øger fleksibilitet og genbrug af eksisterende kode.
• Strukturelle modeller de forklarer, hvordan man samler objekter og klasser i større strukturer, og holder disse strukturer fleksible og effektive.
• Adfærdsmodeller de beskæftiger sig med effektiv kommunikation og tildeling af ansvar mellem objekter.

Eksempel på designmønster i Laravel: Facade

facade er et strukturelt designmønster, der giver en forenklet grænseflade til et bibliotek, et framework eller et hvilket som helst andet komplekst sæt klasser.

problemet

Lad os antage, at vi skal få software til at fungere, baseret på et stort sæt objekter, der hører til et sofistikeret bibliotek eller framework. Normalt skal vi initialisere alle disse objekter, holde styr på afhængigheder, udføre metoder i den rigtige rækkefølge og så videre.

Som følge heraf ville klassernes forretningslogik blive tæt koblet til implementeringsdetaljerne for tredjepartsklasser, hvilket gør dem svære at forstå og administrere.

Opløsning

en facade er en klasse, der giver en enkel grænseflade til et komplekst delsystem, der indeholder mange bevægelige dele. EN facade kan give begrænset funktionalitet sammenlignet med at arbejde direkte med delsystemet. Det inkluderer dog kun de funktioner, som kunderne virkelig bekymrer sig om.

Har en facade det er nyttigt, når vi skal integrere appen med et sofistikeret bibliotek, der har snesevis af funktioner, men vi har kun brug for en lille del af dets funktionalitet.

For eksempel kan en app, der uploader korte sjove videoer med katte til sociale medier, potentielt bruge et professionelt videokonverteringsbibliotek. Men alt, hvad vi virkelig har brug for, er en klasse med den enkelte metode encode(filename, format). Efter at have oprettet en sådan klasse og tilsluttet den til videokonverteringsbiblioteket, har vi vores første facade.

For eksempel er telefonoperatøren af ​​et callcenter som en facade. Faktisk, når vi ringer til en butiks telefontjeneste for at afgive en telefonbestilling, er en operatør vores facade over for alle butikkens tjenester og afdelinger. Operatøren leverer en simpel stemmegrænseflade til bestillingssystemet, betalingsgateways og forskellige leveringstjenester.

Rigtigt eksempel i PHP

Tænke over facade som en simpel adapter til nogle komplekse undersystemer. Facade isolerer kompleksiteten inden for en enkelt klasse og tillader anden applikationskode at bruge den enkle grænseflade.

I dette eksempel, Facade skjuler kompleksiteten af ​​YouTube API og FFmpeg-biblioteket fra klientkoden. I stedet for at arbejde med snesevis af klasser, bruger klienten en simpel metode på Facade.

<?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