Que son os patróns de deseño: por que usalos, clasificación, pros e contras

En enxeñaría de software, os patróns de deseño son solucións óptimas para os problemas que ocorren habitualmente no deseño de software.

Son como preproxectosdefiFerramentas definitivas e probadas que pode personalizar para resolver un problema de deseño recorrente no seu código.

Tempo estimado de lectura: 6 minutos

Que é un patrón de deseño

Un patrón de deseño non é un código que podemos copiar e inserir no noso programa, como podemos facer con funcións ou bibliotecas estándar. O patrón de deseño é un concepto xeral capaz de resolver un problema particular. Basicamente un modelo cuxos detalles podemos seguir e implementar unha solución que se axuste á realidade do noso programa.

Os modelos adoitan confundirse con algoritmos, porque ambos conceptos describen solucións típicas a algúns problemas coñecidos. Mentres un algoritmo defiSe sempre hai un conxunto claro de accións que poden acadar un determinado obxectivo, un modelo é unha descrición de nivel superior dunha solución. O código do mesmo modelo aplicado a dous programas diferentes pode ser diferente.

Querendo facer unha analoxía, podemos pensar nunha receita de cociña: ambos teñen claros os pasos para conseguir un obxectivo. Non obstante, un modelo parécese máis a un proxecto, do que podes ver cal é o resultado e as súas características, pero a orde exacta de implementación depende de nós quen escribamos o código.

De que está feito un patrón de deseño?

A maioría dos patróns descríbense de forma moi formal para que a xente poida reproducilos en moitos contextos. Vexamos a continuación os elementos que están presentes na descrición dun modelo:

• A intención do modelo describe brevemente tanto o problema como a solución.
• A motivación explica ademais o problema e a solución que o modelo fai posible.
• Estrutura de clases mostra cada parte do modelo e como están relacionadas.
• Exemplo de código nunha das linguaxes de programación máis populares facilita a comprensión da idea detrás do modelo.

Por que usalos?

Un programador pode desenvolver software sen coñecer a existencia de patróns de deseño. Moitos si, e por iso implementan algúns esquemas sen sabelo. Pero entón por que debemos dedicar tempo a aprendelas?

• Os patróns de deseño son un kit de solucións probadas e probadas a problemas comúns no deseño de software. Aínda que nunca te atopes con estes problemas, coñecer patróns segue sendo útil porque che ensina a resolver todo tipo de problemas utilizando principios de deseño orientado a obxectos.
• Os modelos de deseño defiCrean unha linguaxe común que ti e o teu equipo podes usar para comunicarte de forma máis eficaz. Podes dicir: "Oh, só usa un Singleton para facelo" e todos entenderán a idea detrás da túa suxestión. Non hai que explicar o que é un singleton se coñeces o patrón e o seu nome.

Clasificación dos patróns de deseño

Os patróns de deseño difiren en complexidade, nivel de detalle e escala de aplicabilidade ao longo do sistema deseñado.

Por analoxía, podemos facer unha intersección máis segura instalando uns poucos semáforos ou construíndo todo un intercambio multinivel con pasos subterráneos para peóns.

Os modelos máis básicos e de baixo nivel adoitan chamarse modismos . Normalmente só se aplican a unha única linguaxe de programación.

Os modelos máis universais e de alto nivel son modelos arquitectónicos . Os desenvolvedores poden implementar estes patróns en practicamente calquera idioma. A diferenza doutros patróns, pódense usar para deseñar a arquitectura dunha aplicación enteira.

Ademais, todos os modelos pódense clasificar segundo o seu probado ou propósito. As tres clases principais son:

• Modelos de creación proporcionan mecanismos de creación de obxectos que aumentan a flexibilidade e a reutilización do código existente.
• Modelos estruturais explican como ensamblar obxectos e clases en estruturas máis grandes, mantendo estas estruturas flexibles e eficientes.
• Modelos de comportamento tratan dunha comunicación eficaz e da asignación de responsabilidades entre obxectos.

Exemplo de patrón de deseño en Laravel: fachada

Fachada é un patrón de deseño estrutural que proporciona unha interface simplificada para unha biblioteca, marco ou calquera outro conxunto complexo de clases.

problema

Supoñamos que necesitamos facer que o software funcione, baseado nun gran conxunto de obxectos que pertencen a unha biblioteca ou marco sofisticado. Normalmente, necesitaríamos inicializar todos estes obxectos, facer un seguimento das dependencias, executar métodos na orde correcta, etc.

Como resultado, a lóxica empresarial das clases quedaría estreitamente vinculada aos detalles de implementación de clases de terceiros, o que dificultaría a súa comprensión e xestión.

Solución

un facade é unha clase que proporciona unha interface sinxela a un subsistema complexo que contén moitas partes móbiles. A facade pode proporcionar unha funcionalidade limitada en comparación co traballo directo co subsistema. Non obstante, só inclúe as funcións que realmente lles importan aos clientes.

Ten un facade é útil cando necesitamos integrar a aplicación cunha biblioteca sofisticada que ten ducias de funcións, pero só necesitamos unha pequena parte da súa funcionalidade.

Por exemplo, unha aplicación que carga vídeos curtos e divertidos con gatos ás redes sociais podería utilizar unha biblioteca de conversión de vídeo profesional. Non obstante, o único que necesitamos é unha clase co método único encode(filename, format). Despois de crear unha clase deste tipo e conectala á biblioteca de conversión de vídeo, teremos a nosa primeira facade.

Por exemplo, o operador de telefonía dun centro de chamadas é como a facade. De feito, cando chamamos ao servizo telefónico dunha tenda para facer un pedido telefónico, un operador é noso facade cara a todos os servizos e departamentos da tenda. O operador ofrece unha interface de voz sinxela para o sistema de pedidos, pasarelas de pago e varios servizos de entrega.

Exemplo real en PHP

Pensar Fachada como un simple adaptador para algúns subsistemas complexos. Facade illa a complexidade nunha única clase e permite que outro código de aplicación use a interface sinxela.

Neste exemplo, Facade oculta a complexidade da API de YouTube e da biblioteca FFmpeg do código do cliente. En lugar de traballar con ducias de clases, o cliente usa un método sinxelo en 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