Ludo Programming

În lumea dezvoltării software, un design pattern (model de proiectare) este o soluție generală, testată în timp, pentru o problemă recurentă de arhitectură sau structură a codului. Nu este un cod gata de folosit, ci un șablon conceptual care te ajută să proiectezi aplicații flexibile, extensibile și ușor de întreținut.

În .NET, aceste modele sunt folosite zilnic, fie că lucrezi cu Blazor, ASP.NET Core, MAUI sau aplicații de tip microserviciu. Fiecare pattern rezolvă o problemă comună — cum creezi obiecte, cum le legi între ele și cum gestionezi comportamentul lor.

🔧 De ce avem nevoie de design patterns

În teorie, putem scrie orice cod fără ele. În practică, însă, apar rapid probleme:

• logica devine duplicată și greu de întreținut;

• clasele ajung să depindă prea mult unele de altele;

• modificările introduc bug-uri neașteptate;

• proiectul devine rigid și greu de extins.

Design pattern-urile oferă un vocabular comun și o disciplină arhitecturală. Când un programator spune „folosim un Factory aici” sau „acest serviciu e un Singleton”, toată echipa înțelege instant intenția și rolul acelui cod.

🧠 Tipurile principale de design patterns

Modelele sunt grupate în trei mari categorii, fiecare cu un scop clar:

1. Creational Patterns – controlează procesul de creare a obiectelor (ex: Singleton, Factory, Builder).

2. Structural Patterns – definesc cum se compun clasele și obiectele între ele (ex: Adapter, Decorator, Facade).

3. Behavioral Patterns – se ocupă de interacțiunea și comunicarea dintre obiecte (ex: Observer, Strategy, Command).

Aceste trei grupe formează „trilogia clasică” introdusă în cartea Design Patterns: Elements of Reusable Object-Oriented Software (Gang of Four, 1994), care stă și azi la baza arhitecturii moderne în .NET.

💡 Exemplu practic – de ce contează un pattern

Să presupunem că ai o aplicație .NET care trimite notificări (email, SMS, push). Fără un design clar, codul tău ar putea arăta așa:

public class NotificationService
{
    public void Send(string type, string message)
    {
        if (type == "email")
            Console.WriteLine($"Email: {message}");
        else if (type == "sms")
            Console.WriteLine($"SMS: {message}");
        else if (type == "push")
            Console.WriteLine($"Push: {message}");
    }
}

Pare simplu, dar e o capcană clasică. De fiecare dată când adaugi un nou tip de notificare, modifici metoda Send(). Asta încalcă Open/Closed Principle (clasa trebuie să fie deschisă pentru extindere, dar închisă pentru modificare).

Aplicând un pattern (de exemplu, Factory Method), poți delega crearea tipului de notificare unei clase separate:

public interface INotifier
{
    void Send(string message);
}

public class EmailNotifier : INotifier
{
    public void Send(string message) => Console.WriteLine($"Email: {message}");
}

public class SmsNotifier : INotifier
{
    public void Send(string message) => Console.WriteLine($"SMS: {message}");
}

public static class NotifierFactory
{
    public static INotifier Create(string type) =>
        type switch
        {
            "email" => new EmailNotifier(),
            "sms" => new SmsNotifier(),
            _ => throw new NotSupportedException()
        };
}

Acum, codul principal devine curat și extensibil:

var notifier = NotifierFactory.Create("email");
notifier.Send("Salut din LudoProgramming!");

Dacă mâine vrei un PushNotifier, doar adaugi o nouă clasă — fără să atingi codul existent.

Exact acesta e spiritul design pattern-urilor: ordine, extensibilitate și claritate.

🚀 Concluzie

Design pattern-urile nu sunt doar concepte teoretice, ci instrumente concrete pentru orice programator .NET care vrea să scrie cod profesionist.

Ele reduc complexitatea, cresc reutilizarea și fac codul tău mai ușor de înțeles de alții.