La lliçó anterior va polir l'estil del codi de BiblioTech: noms, comentaris, documentació, nul·labilitat. Aquesta lliçó fa un pas més enllà de l'estil, cap al disseny: com organitzar les relacions entre classes per resoldre problemes que apareixen una i altra vegada en qualsevol projecte orientat a objectes. Un patró de disseny és, precisament, una solució ja provada a un d'aquests problemes recurrents —no codi que es copia literalment, sinó una manera de pensar l'estructura de les classes implicades—. Veuràs tres famílies clàssiques de patrons i n'aplicaràs dos directament sobre el domini de BiblioTech: Factory Method per crear materials bibliotecaris, i Strategy per calcular sancions per retard. Descobriràs, a més, que un dels patrons de comportament més coneguts —Observer— ja porta diversos mòduls aplicat a BiblioTech, sense que se li hagués posat nom fins ara.

1. Què és un patró de disseny i per què importa
2. Patrons creacionals: Singleton i Factory Method
3. Patrons estructurals: Adapter i Decorator
4. Patrons de comportament: Strategy i Observer
5. Taula resum: quan fer servir cada patró
6. Exemple: Factory Method per crear MaterialBibliotecari
7. Exemple: Strategy per a polítiques de càlcul de sancions

Un patró de disseny no és una biblioteca que s'instal·la ni una sintaxi nova de C#: és una plantilla conceptual, documentada i amb nom propi, per resoldre un problema de disseny que es repeteix en projectes molt diferents entre si. La idea es va popularitzar amb el llibre Design Patterns (1994, l'anomenat "Gang of Four"), que va catalogar vint-i-tres patrons agrupats en tres famílies:

Conèixer aquests patrons importa per dues raons pràctiques: primer, donen vocabulari comú —dir "això és un Observer" comunica de cop tota una estructura a un altre desenvolupador, sense haver-la d'explicar des de zero—; segon, eviten reinventar pitjor una solució que ja està provada i té avantatges i inconvenients ben coneguts. No es tracta de forçar un patró a cada classe que s'escriu —un patró mal aplicat on no cal afegeix complexitat innecessària—, sinó de reconèixer quan el problema que tens al davant ja té una solució de disseny amb nom.

Singleton garanteix que una classe té una única instància a tota l'aplicació, i ofereix un punt d'accés global a ella:

El constructor private impedeix crear instàncies amb new des de fora de la classe; l'única via d'accés és la propietat estàtica Instancia, que crea l'objecte la primera vegada que es demana (??=, l'operador d'assignació condicional nul·la) i retorna sempre aquesta mateixa referència després. Singleton és útil per a configuració global compartida, però convé fer-lo servir amb moderació: abusar-ne dificulta les proves unitàries (Lliçó 4 d'aquest mòdul), perquè introdueix un estat global ocult que és difícil de substituir per una versió de prova.

Factory Method encapsula la lògica de quina classe concreta crear dins d'un mètode dedicat, en comptes d'escampar crides a new TipusConcret(...) per tot el programa. Qui demana un objecte no necessita saber la classe exacta que rebrà, només el tipus base o la interfície comuna:

El codi que crida FabricaMaterial.Crear no escriu new Llibre(...) ni new Revista(...) directament: delega aquesta decisió a la fàbrica, a partir d'un simple string. Això centralitza en un únic lloc la lògica de "quina classe concreta correspon a cada tipus", en comptes de repetir-la —amb el risc que es desincronitzi— a cada punt del programa que necessiti crear un material. L'apartat 6 amplia aquest exemple amb més detall.

Adapter adapta la interfície d'una classe existent (sovint, una que no es pot modificar) perquè encaixi amb la interfície que la resta del codi espera. Imagina un servei extern de catàleg de biblioteques que exposa les seves dades amb noms de camp diferents als de BiblioTech:

AdaptadorCatalegExtern hereta de MaterialBibliotecari i, per dins, tradueix les crides a GetBookTitle()/GetBookAuthor() de CatalegExternLlegat cap al constructor que MaterialBibliotecari ja espera. La resta de BiblioTech pot tractar un material que ve d'aquest servei extern exactament igual que un Llibre o una Revista propis, sense conèixer mai la interfície original de CatalegExternLlegat.

Decorator afegeix responsabilitats a un objecte embolcallant-lo, sense modificar-ne la classe ni fer servir herència per a cada combinació possible de comportaments afegits:

MaterialAmbEtiquetaNova embolcalla qualsevol MaterialBibliotecari i li afegeix el prefix [NOU] a la seva descripció, sense tocar ni Llibre ni Revista ni necessitar una classe LlibreNou/RevistaNova separada per a cada combinació. Es podrien encadenar diversos decoradors (per exemple, un que afegeixi [DESTACAT] sobre l'anterior) per combinar comportaments de forma flexible.

Strategy encapsula un algorisme intercanviable darrere d'una interfície comuna, de manera que l'algorisme concret es pot canviar en temps d'execució sense tocar el codi que l'usa. L'apartat 7 ho desenvolupa en profunditat amb les polítiques de sancions de Prestec.

Observer defineix una dependència d'un a molts entre objectes: quan un objecte (el subjecte) canvia d'estat, tots els seus observadors són notificats automàticament, sense que el subjecte necessiti conèixer-los per endavant. Repassa l'esdeveniment PrestecRegistrat de Biblioteca, introduït a la lliçó de Delegats i Esdeveniments del Mòdul 4:

Sense que ningú li hagués posat nom fins ara, aquesta estructura és el patró Observer: Biblioteca és el subjecte, cada mètode subscrit amb += és un observador, i event és el mecanisme concret que C# ofereix per implementar aquest patró de forma segura (recorda la lliçó de Delegats i Esdeveniments: event impedeix invocar o reemplaçar la llista de subscriptors des de fora de la classe). És habitual trobar-se que ja s'ha fet servir un patró de disseny sense saber-ho —reconèixer-ho ara, amb nom, ajuda a raonar-hi amb el vocabulari compartit de la comunitat C#, i a reconèixer la mateixa estructura la propera vegada que aparegui.

Retomant FabricaMaterial de l'apartat 2, una versió més completa que reflecteix com es faria servir a BiblioTech en importar materials des d'una font externa (per exemple, un fitxer CSV o una resposta JSON, Mòdul 5) on el tipus de material arriba com a text:

Si BiblioTech afegís en el futur un tercer tipus de material (per exemple, AudioLlibre), l'únic canvi necessari seria afegir un nou cas al switch de FabricaMaterial.Crear; cap altre punt del programa que ja cridi la fàbrica necessitaria modificar-se.

BiblioTech necessita calcular una sanció quan un préstec es retorna amb retard. En comptes d'escriure aquesta lògica directament dins de Prestec (cosa que obligaria a modificar la classe cada vegada que canviés la política de sancions), Strategy l'extreu a una interfície intercanviable:

SancioFixa cobra sempre el mateix si hi ha retard, sense importar quants dies; SancioProgressiva cobra més com més dies de retard hi hagi. Totes dues implementen la mateixa interfície IPoliticaSancio, així que són intercanviables entre si. Prestec rep la política a aplicar sense conèixer els detalls de cap de les dues implementacions:

CalcularSancio rep la política com a paràmetre (IPoliticaSancio politica): Prestec no sap, ni necessita saber, si s'està aplicant SancioFixa, SancioProgressiva, o una tercera política que s'afegeixi en el futur (per exemple, una que eximeixi de sanció els socis amb una antiguitat determinada). Canviar de política —fins i tot en temps d'execució, decidint quina fer servir segons alguna condició— no requereix cap modificació a Prestec.

• Forçar un patró on no cal: aplicar Strategy per a un if/else que mai canviarà, o Decorator per a una única variació que mai es combina amb una altra, afegeix complexitat sense cap benefici real. Els patrons resolen problemes de variació i creixement; si no existeix aquest problema, el codi directe i senzill és la millor opció.
• Confondre Adapter amb Decorator: tots dos "embolcallen" un objecte, però amb propòsits diferents: Adapter tradueix una interfície incompatible a l'esperada; Decorator afegeix comportament a una interfície que ja era compatible des del principi.
• Abusar de Singleton per a "qualsevol cosa global": Singleton dificulta les proves unitàries (Lliçó 4) perquè introdueix un estat compartit difícil de substituir per una versió de prova. La Lliçó 3 d'aquest mòdul (Injecció de Dependències) ofereix, per a la majoria de casos, una alternativa més flexible i més fàcil de provar.
• Consell: no memoritzis els vint-i-tres patrons del catàleg original; n'hi ha prou amb reconèixer, quan apareix un problema conegut (crear objectes segons un tipus variable, notificar diversos interessats, intercanviar un algorisme), quin patró ja resol exactament aquest problema.

1. Afegeix a FabricaMaterial.Crear (apartat 6) un tercer cas per a un tipus "audiollibre" que creï una classe AudioLlibre : MaterialBibliotecari (pots assumir que ja existeix, amb un constructor AudioLlibre(string titol, string autor, int duracioMinuts)), interpretant dadaAddicional com la durada en minuts.

2. Implementa una tercera política IPoliticaSancio anomenada SenseSancio, que sempre retorni 0m sense importar els dies de retard, i explica en una frase en quin escenari de BiblioTech tindria sentit fer-la servir.

public static MaterialBibliotecari Crear(string tipus, string titol, string autor, string dadaAddicional)
{
    return tipus.ToLower() switch
    {
        "llibre" => new Llibre(titol, autor, isbn: dadaAddicional),
        "revista" => new Revista(titol, autor, numeroEdicio: int.Parse(dadaAddicional)),
        "audiollibre" => new AudioLlibre(titol, autor, duracioMinuts: int.Parse(dadaAddicional)),
        _ => throw new ArgumentException($"Tipus de material desconegut: '{tipus}'")
    };
}

class SenseSancio : IPoliticaSancio
{
    public decimal CalcularSancio(int diesRetard) => 0m;
}

Tindria sentit, per exemple, per a socis amb algun tipus de bonificació (personal de la mateixa biblioteca, o una promoció temporal), on es vol reutilitzar tota la lògica de Prestec.CalcularSancio sense aplicar cap penalització econòmica real.

En aquesta lliçó has conegut què és un patró de disseny i per què dona vocabulari comú i solucions ja provades, has vist Singleton i Factory Method (creacionals), Adapter i Decorator (estructurals), i Strategy i Observer (de comportament) —descobrint que aquest últim ja portava aplicat a Biblioteca.PrestecRegistrat des del Mòdul 4—, i has aplicat Factory Method per centralitzar la creació de materials i Strategy per fer intercanviables les polítiques de sanció de Prestec. La lliçó següent retoma en profunditat un mecanisme que ja va aparèixer esmentat de passada a diverses interfícies del Mòdul 7 (ASP.NET Core, Blazor, MAUI): la injecció de dependències, que resulta ser, en el fons, una forma sistemàtica d'aplicar el mateix principi que fa possible Strategy —programar contra interfícies, no contra implementacions concretes— a tot el projecte BiblioTech.