Wat zijn ontwerppatronen: waarom ze gebruiken, classificatie, voor- en nadelen

In software-engineering zijn ontwerppatronen optimale oplossingen voor problemen die vaak voorkomen bij softwareontwerp.

Het zijn een soort voorprojectendefiEinde, beproefde tools die u kunt aanpassen om een ​​terugkerend ontwerpprobleem in uw code op te lossen.

Geschatte leestijd: 6 minuti

Wat is een ontwerppatroon

Een ontwerppatroon is geen code die we kunnen kopiëren en in ons programma kunnen invoegen, zoals we dat met standaardfuncties of bibliotheken kunnen doen. Het ontwerppatroon is een algemeen concept dat een bepaald probleem kan oplossen. Eigenlijk een model waarvan we de details kunnen volgen en een oplossing kunnen implementeren die past bij de realiteit van ons programma.

Modellen worden vaak verward met algoritmen, omdat beide concepten typische oplossingen voor enkele bekende problemen beschrijven. Hoewel een algoritme defiAls er altijd een duidelijke reeks acties is die een bepaald doel kunnen bereiken, is een model een beschrijving op een hoger niveau van een oplossing. Code van hetzelfde model toegepast op twee verschillende programma's kan verschillend zijn.

Als we een analogie willen maken, kunnen we een kookrecept bedenken: beide hebben duidelijke stappen om een ​​doel te bereiken. Een model lijkt echter meer op een project, waarvan je kunt zien wat het resultaat en de kenmerken ervan zijn, maar de exacte volgorde van implementatie hangt af van ons die de code schrijft.

Waar is een ontwerppatroon van gemaakt?

De meeste patronen worden zeer formeel beschreven, zodat mensen ze in veel contexten kunnen reproduceren. Laten we hieronder de elementen bekijken die aanwezig zijn in de beschrijving van een model:

• De bedoeling van het model beschrijft kort zowel het probleem als de oplossing.
• De motivatie legt het probleem verder uit en de oplossing die het model mogelijk maakt.
• De structuur van klassen toont elk onderdeel van het model en hoe deze met elkaar in verband staan.
• Het codevoorbeeld in een van de meest populaire programmeertalen maakt het gemakkelijker om het idee achter het model te begrijpen.

Waarom ze gebruiken?

Een programmeur kan software ontwikkelen zonder het bestaan ​​van ontwerppatronen te kennen. Velen doen dat, en om deze reden implementeren ze sommige plannen zonder het te weten. Maar waarom zouden we dan tijd besteden aan het leren ervan?

• De ontwerppatronen zijn een bouwpakket beproefde oplossingen voor veelvoorkomende problemen bij het ontwerpen van software. Zelfs als je deze problemen nooit tegenkomt, is het kennen van patronen nog steeds nuttig omdat het je leert hoe je allerlei problemen kunt oplossen met behulp van objectgeoriënteerde ontwerpprincipes.
• De ontwerpmodellen defiZe creëren een gemeenschappelijke taal die u en uw team kunnen gebruiken om effectiever te communiceren. Je zou kunnen zeggen: "Oh, gebruik hiervoor gewoon een Singleton", en iedereen zal het idee achter jouw suggestie begrijpen. Het is niet nodig om uit te leggen wat een singleton is als je het patroon en de naam kent.

Classificatie van ontwerppatronen

Ontwerppatronen verschillen in complexiteit, detailniveau en schaal van toepasbaarheid binnen het ontworpen systeem.

Naar analogie kunnen we een kruispunt veiliger maken door een paar verkeerslichten te plaatsen of een heel kruispunt met meerdere niveaus aan te leggen met ondergrondse passages voor voetgangers.

Vaak worden de meest basale modellen op laag niveau genoemd idiomen . Ze zijn meestal alleen van toepassing op één enkele programmeertaal.

De meest universele en hoogwaardige modellen zijn dat wel architectonische modellen . Ontwikkelaars kunnen deze patronen in vrijwel elke taal implementeren. In tegenstelling tot andere patronen kunnen ze worden gebruikt om de architectuur van een volledige applicatie te ontwerpen.

Bovendien kunnen alle modellen worden geclassificeerd op basis van hun poging of doel. De drie hoofdklassen zijn:

• Creationele modellen ze bieden mechanismen voor het maken van objecten die de flexibiliteit en het hergebruik van bestaande code vergroten.
• Structurele modellen ze leggen uit hoe je objecten en klassen in grotere structuren kunt samenvoegen, waardoor deze structuren flexibel en efficiënt blijven.
• Gedragsmodellen ze houden zich bezig met effectieve communicatie en toewijzing van verantwoordelijkheden tussen objecten.

Voorbeeld van ontwerppatroon in Laravel: gevel

Gevel is een structureel ontwerppatroon dat een vereenvoudigde interface biedt voor een bibliotheek, raamwerk of een andere complexe reeks klassen.

het probleem

Laten we aannemen dat we software moeten laten werken, gebaseerd op een groot aantal objecten die tot een geavanceerde bibliotheek of raamwerk behoren. Normaal gesproken zouden we al deze objecten moeten initialiseren, afhankelijkheden moeten bijhouden, methoden in de juiste volgorde moeten uitvoeren, enzovoort.

Als gevolg hiervan zou de bedrijfslogica van de klassen nauw gekoppeld raken aan de implementatiedetails van klassen van derden, waardoor ze moeilijk te begrijpen en te beheren zijn.

oplossing

een facade is een klasse die een eenvoudige interface biedt voor een complex subsysteem dat veel bewegende delen bevat. A facade kan beperkte functionaliteit bieden in vergelijking met rechtstreeks werken met het subsysteem. Het bevat echter alleen de functies waar klanten echt om geven.

Heb er een facade het is handig als we de app moeten integreren met een geavanceerde bibliotheek die tientallen functies heeft, maar we hebben slechts een klein deel van de functionaliteit nodig.

Een app die korte grappige video's met katten naar sociale media uploadt, zou bijvoorbeeld mogelijk een professionele videoconversiebibliotheek kunnen gebruiken. Het enige dat we echt nodig hebben, is echter een klasse met de enkele methode encode(filename, format). Nadat we zo'n klasse hebben gemaakt en deze aan de videoconversiebibliotheek hebben gekoppeld, hebben we onze eerste facade.

De telefoonoperator van een callcenter is bijvoorbeeld als een facade. Als wij de telefoondienst van een winkel bellen om een ​​telefonische bestelling te plaatsen, is er in feite een telefoniste bij ons facade richting alle diensten en afdelingen van de winkel. De operator biedt een eenvoudige spraakinterface voor het bestelsysteem, betalingsgateways en verschillende bezorgdiensten.

Echt voorbeeld in PHP

Denk erover na Gevel als een eenvoudige adapter voor enkele complexe subsystemen. Facade isoleert de complexiteit binnen een enkele klasse en zorgt ervoor dat andere applicatiecode de eenvoudige interface kan gebruiken.

In dit voorbeeld Facade verbergt de complexiteit van de YouTube API en FFmpeg-bibliotheek voor de clientcode. In plaats van met tientallen klassen te werken, gebruikt de klant een eenvoudige methode op 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