Какво представляват шаблоните за проектиране: защо да ги използваме, класификация, плюсове и минуси

В софтуерното инженерство моделите на проектиране са оптимални решения на проблеми, които често възникват при проектирането на софтуер.

Те са като предпроектиdefiкрайни, изпитани и тествани инструменти, които можете да персонализирате, за да разрешите повтарящ се проблем с дизайна във вашия код.

Очаквано време за четене: 6 Minuti

Какво е дизайн модел

Моделът на проектиране не е код, който можем да копираме и вмъкнем в нашата програма, както можем да направим със стандартни функции или библиотеки. Моделът на проектиране е обща концепция, способна да реши конкретен проблем. По принцип модел, чиито детайли можем да следваме и да приложим решение, което отговаря на реалността на нашата програма.

Моделите често се бъркат с алгоритми, тъй като и двете концепции описват типични решения на някои известни проблеми. Докато алгоритъм defiАко винаги има ясен набор от действия, които могат да постигнат определена цел, моделът е описание на решение от по-високо ниво. Кодът от един и същ модел, приложен към две различни програми, може да е различен.

Искайки да направим аналогия, можем да се сетим за рецепта за готвене: и двете имат ясни стъпки за постигане на цел. Все пак моделът е по-скоро проект, от който можете да видите какъв е резултатът и неговите характеристики, но точният ред на внедряване зависи от нас, които пишем кода.

От какво е направен шаблонът за проектиране?

Повечето модели са описани много официално, така че хората да могат да ги възпроизвеждат в много контексти. Нека видим по-долу елементите, които присъстват в описанието на даден модел:

• Намерението на модела описва накратко както проблема, така и решението.
• Мотивацията допълнително обяснява проблема и решението, което моделът прави възможно.
• Структура от класове показва всяка част от модела и как те са свързани.
• Примерът за код на един от най-популярните програмни езици улеснява разбирането на идеята зад модела.

Защо да ги използваме?

Програмистът може да разработи софтуер, без да знае за съществуването на модели на проектиране. Мнозина го правят и поради тази причина прилагат някакви схеми, без да го знаят. Но защо тогава трябва да отделяме време за изучаването им?

• Шаблоните за проектиране са комплект от изпитани решения към често срещани проблеми в софтуерния дизайн. Дори ако никога не се сблъсквате с тези проблеми, познаването на моделите все още е полезно, защото ви учи как да решавате всякакви проблеми, като използвате обектно-ориентирани принципи на проектиране.
• Дизайнерските модели defiТе създават общ език, който вие и вашият екип можете да използвате, за да общувате по-ефективно. Бихте могли да кажете: „О, просто използвайте Singleton, за да направите това“ и всеки ще разбере идеята зад вашето предложение. Няма нужда да обяснявате какво е сингълтън, ако знаете модела и името му.

Класификация на дизайн моделите

Шаблоните за проектиране се различават по сложност, ниво на детайлност и мащаб на приложимост в цялата проектирана система.

По аналогия можем да направим едно кръстовище по-безопасно, като монтираме няколко светофара или изградим цял многоетажен възел с подземни проходи за пешеходци.

Често се наричат ​​най-основните модели на ниско ниво идиоми . Те обикновено се прилагат само за един език за програмиране.

Най-универсалните и висококачествени модели са архитектурни модели . Разработчиците могат да прилагат тези модели на почти всеки език. За разлика от други модели, те могат да се използват за проектиране на архитектурата на цяло приложение.

Освен това всички модели могат да бъдат класифицирани според техните опитах или цел. Трите основни класа са:

• Творчески модели те предоставят механизми за създаване на обекти, които увеличават гъвкавостта и повторното използване на съществуващия код.
• Структурни модели те обясняват как да се сглобяват обекти и класове в по-големи структури, поддържайки тези структури гъвкави и ефективни.
• Поведенчески модели те се занимават с ефективна комуникация и разпределяне на отговорности между обектите.

Пример за модел на дизайн в Laravel: Фасада

Фасада е структурен модел на проектиране, който предоставя опростен интерфейс към библиотека, рамка или друг сложен набор от класове.

Проблем

Да приемем, че трябва да накараме софтуера да работи въз основа на голям набор от обекти, които принадлежат към сложна библиотека или рамка. Обикновено трябва да инициализираме всички тези обекти, да следим зависимостите, да изпълняваме методи в правилния ред и т.н.

В резултат на това бизнес логиката на класовете ще стане тясно свързана с подробностите за внедряването на класове на трети страни, което ги прави трудни за разбиране и управление.

Решение

а facade е клас, който предоставя прост интерфейс към сложна подсистема, която съдържа много движещи се части. А facade може да осигури ограничена функционалност в сравнение с работата директно с подсистемата. Той обаче включва само функциите, от които клиентите наистина се интересуват.

Има един facade полезно е, когато трябва да интегрираме приложението със сложна библиотека, която има десетки функции, но се нуждаем само от малка част от неговата функционалност.

Например, приложение, което качва кратки забавни видеоклипове с котки в социални медии, може потенциално да използва професионална библиотека за преобразуване на видео. Въпреки това, всичко, от което наистина се нуждаем, е клас с единствен метод encode(filename, format). След като създадем такъв клас и го свържем с библиотеката за преобразуване на видео, ще имаме нашия първи facade.

Например телефонният оператор на кол център е като a facade. Всъщност, когато се обадим на телефонната служба на магазина, за да направим поръчка по телефона, операторът е нашият facade към всички услуги и отдели на магазина. Операторът предоставя прост гласов интерфейс към системата за поръчки, шлюзове за плащане и различни услуги за доставка.

Реален пример в PHP

Мисля за Фасада като прост адаптер за някои сложни подсистеми. Facade изолира сложността в рамките на един клас и позволява на друг код на приложение да използва простия интерфейс.

В този пример, Facade скрива сложността на API на YouTube и библиотеката FFmpeg от клиентския код. Вместо да работи с десетки класове, клиентът използва прост метод на 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