Organisering af kode vil spare os for en masse smerte. Ved hjælp af funktionerne i objektorienteret programmering kan vi anvende visse designmønstre for at opnå bedre læsbarhed, reducere redundans og skabe abstraktioner, hvis det er nødvendigt. Et sådant mønster er fabriksmønsteret.
Fabriksmønsteret er en type objektorienteret mønster, der følger DRY-metodologien. Som navnet antyder, oprettes objektinstanser ved at bruge en fabrik til at fremstille det ønskede objekt for os.
Lad os se på et meget simpelt eksempel på at bruge fabriksmønstret til at samle et alligator objekt. For at gøre det skal vi først lave fabrikker, der skaber alligator-delene for os:
class TailFactory { constructor(props) { this.tailLength = props.tailLength; }};class TorsoFactory { constructor(props) { this.color = props.color; }};class HeadFactory { constructor(props) { this.snoutLenth = props.snoutLenth; }};Nu opretter vi en klasse, der fungerer som mellemmand mellem de faktiske fabrikkeklasser og brugeren. Lad os kalde denne ReptilePartFactory:
class ReptilePartFactory { constructor(type, props) { if(type === "tail") return new TailFactory(props); if(type === "torso") return new TorsoFactory(props); if(type === "head") return new HeadFactory(props); }};Lad os gå videre og samle den egentlige alligator nu og bruge ReptilePartFactory til at få de nødvendige dele til os:
let alligator = {};let alligatorProps = { tailLength : 2.5, color: "green", snoutLenth: 1};//gets a tail from the tail factoryalligator.tail = new ReptilePartFactory("tail", alligatorProps); //gets a torso from the torso factoryalligator.torso = new ReptilePartFactory("torso", alligatorProps);//gets a head from the head factoryalligator.head = new ReptilePartFactory("head", alligatorProps);Tager vi et kig på mønsteret ovenfor, ser det ud til, at vi kan bruge den samme ReptilePartFactory til at skabe dele til alligatorlignende objekter. Fabrikkerne i baggrunden ville aldrig behøve at vide noget om det endelige objekts art.
Derved giver brugen af fabriksmønsteret os visse fordele:
- Dynamisk objektoprettelse: Det kan bruges i tilfælde, hvor objektets type bestemmes på køretid.
- Abstraktion:
- Genanvendelighed/vedligeholdelse: Brugeren behøver aldrig rigtig at få adgang til det egentlige objekts konstruktør.
- Genanvendelighed/vedligeholdelse: Samme fabrikker kan bruges til lignende objekter, og det giver os mulighed for nemt at tilføje/fjern nye objektklasser uden at ændre en masse kode.
Nu da vi har en vis forståelse af fabriksmønsteret, skal vi udforske lidt på at skrive bedre kode til fabriksmønsteret.
Eksemplet ovenfor bruger en if-ladder til at finde ud af, hvilken fabrik der skal kaldes baseret på brugerens input. Dette er en simpel implementering, intuitiv og ikke særlig åben over for ændringer. Hvis vi har nye dele, der skal tilføjes senere, skal vi forstyrre ReptilePartFactory. Dette er en overtrædelse af SOLID-principperne, som siger: “Softwareenheder (klasser, moduler, funktioner osv.) bør være åbne for udvidelse, men lukkede for ændring.”
Hvad med at vi gemmer fabriksklasserne i et objekt og kalder den ønskede delfabrik ved at bruge den ønskede del som nøgle? Først skulle vi registrere factories, det ville være så simpelt som:
let registeredPartFactories = {};registeredPartFactories = class TailFactory{ ...};registeredPartFactories = class TorsoFactory { ...};registeredPartFactories = class HeadFactory { ...};Og nu kan det abstrakte lag kalde factories på denne måde:
class ReptilePartFactory { constructor(type, props) { return new registeredPartFactories(props); }};Denne fremgangsmåde er meget renere og giver mulighed for at udvide vores factories uden at påvirke koden i ReptilePartFactory.
Sammenfattende
Der er flere andre objektorienterede mønstre, som også øger læsbarheden og kvaliteten. Så før du bruger fabriksmønsteret, skal du undersøge, om der er et reelt behov for det. Hvis du skal oprette lignende typer objekter gentagne gange og også har brug for et lag til at oprette nye instanser ved hjælp af disse objekter, samtidig med at du giver et vist abstraktionsniveau for oprettelseslogikken, så ja – så er factory-mønstret en god mulighed.