Real World: iOS-designmønstre

Designmønster er et almindeligt emne i samtaler, fora og endda i en 15 min pausesamtale på arbejdet. Du kan finde en masse ting på bøger eller på internettet om det og en masse eksempler ved hjælp af gummi ænder, kaffebar og pizzabutikker .

Da jeg begyndte at studere forstår jeg normalt mønsteret, men jeg havde en masse problemer med at tænke over, hvordan man anvender dem på min kode. Jeg forstår, at fabriksmønsteret bruges til at oprette objekter, men hvorfor har jeg brug for det? Har jeg virkelig brug for en fabrik for at oprette mine objekter?

Mit mål med dette indlæg er at bringe nogle virkelige eksempler på nogle designmønstre, som jeg brugte i mine projekter.

Strategi

Strategimønsteret gør det muligt at vælge en algoritme ved kørsel. I stedet for at implementere en enkelt algoritme direkte, modtager kode runtime-instruktioner om, hvilken i en familie af algoritmer, der skal bruges.

Vi kan bruge forskellige algoritmer runtime-baseret, med andre ord, vi er ligeglad med, hvordan implementeringen udføres.

En algoritme har brug for et objekt, der ved, hvordan man flyver, en Duck-klasse ved også at flyve og en Rocket-klasse. Vores algoritme er ligeglad med, om vores implementering er nødt til at sprede sine vinger eller en gallon gas.

Problem løst ved hjælp af strategi

Det dette projekt havde vi brug for for at kunne modtage en viewController, men vi har også brug for det for at have nogle foruddefinerede opførsler, og det er et perfekt sted at anvende strategimønsteret. En almindelig ViewController i mobile applikationer er et login, så bare opret en protokol, der definerer vores LoginViewController handlinger og afhængigheder.

Jeg mener, at vores LoginViewController kan injiceres i vores projekt, vi er ligeglad med UI, hvis det har en tabelView, nogen animation eller valideringsmetoder, men vi har brug for det for at vide, hvordan man udfører et login. Du kan læse mere om dette særlige problem her.

Fabrik

Fabriksmetodemønsteret håndterer problemet med at oprette objekter uden at skulle specificere den nøjagtige klasse af det objekt, der skal oprettes.

Fabriksmønsteret er nyttigt, når du har brug for at oprette objekter på runtime. Så hvis brugeren ønsker en ostepizza opretter du en CheesePizza (), hvis han / hun ønsker en pepperoni, så PepperoniPizza () ftw.

Problemet løst ved hjælp af fabrikken

I det samme projekt, som vi bruger strategimønsteret til at løse vores viewController-indsprøjtningsproblem, bruger vi et fabriksmønster til at være i stand til at oprette objekter på runtime, der overfører dem alle de afhængigheder, de har brug for.

Vi var nødt til at skubbe til en forekomst af LoginViewController, som kan oprettes ved hjælp af forskellige tilgange som Storyboards, xib eller view-kodet. Vi havde en fabriksinstans, som kan injiceres ved at ændre den måde, objektet, der vil blive oprettet af fabrikken, skifter fabrikken selv.

Med et eksempel på en fabrik skal vi bare kalde build-metoden. Denne fabrik kan være et eksempel på ViewCodedLoginViewControllerFactory eller StoryboardLoginViewControllerFactory vi er ligeglad med, vi har bare brug for den til at implementere build-metoden, der returnerer en LoginViewController.

Her har vi en fabrik til hver slags objekter, men vi kan have en fabrik, der ved, hvordan man bygger en ViewController fra storyboard, xibs eller viewcoded.

Dekoratør

Dekoratormønsteret tillader, at adfærden føjes til et individuelt objekt, enten statisk eller dynamisk, uden at det påvirker opførelsen af ​​andre objekter fra samme klasse.

Dette er mit yndlingsmønster, det klassiske eksempel på dekoratørmønster er kaffebaren, der ønsker at tilføje piskekrem til sin kaffe og beregne den nye pris og beskrivelse baseret på drikkevaren.

Problemet løst ved hjælp af dekoratør

Vi har brug for forskellige API-versioner til hvert servicekald. Dette kan gøres på mange forskellige måder, men vi bruger dette mønster til at tilføje en brugerdefineret Header til en anmodning. Med denne tilgang kan vi også være klar, hvis et API-opkald i fremtiden skulle tilføje en anden parameter til dens overskrift.

Vi var også nødt til at filtrere resultater i en anmodning. Hvilket kan gøres ved at oprette en ny metode eller ændre, hvordan din anmodning fungerer. Vi besluttede at bruge en Decorator til at tilføje denne opførsel, fordi vores service blev brugt i andre klasser, og vi ønsker at ændre det mindst mulige antal linjer i vores tidligere implementering.

adapter

Adaptermønsteret er et software-designmønster, der gør det muligt at bruge en eksisterende klasses interface som en anden interface. Det bruges ofte til at få eksisterende klasser til at arbejde sammen med andre uden at ændre deres kildekode.

Tænk på en adapter som en rigtig adapter. Du har brug for din Nintendo 64 , der har en sammensat video som dens videooutput for at arbejde med dit nye 4k TV . Så du har brug for en Composite-HDMI-adapter.

Problemet løst ved hjælp af adapter

Vi var nødt til at vare fire cifre i en kortmodel og også være kompatible med PKPaymentPass. Med andre ord oprettet en adapter til at omdanne en PKPaymentPass-instans til kort.

Men vi kan også blande mønstre, der skaber mere genanvendelig og vedligeholdelig kode, for eksempel at blande vores adapter med strategimønsteret. Vi har ikke virkelig brug for et kortobjekt, vi har bare brug for de sidste numre, så hvorfor opretter vi ikke en protokol til at gøre det og være kompatibel med PKPaymentPass, kort og ethvert andet objekt, som vores projekt muligvis har brug for.

Langt om længe

Designmønstre hjælper mig meget med at oprette mere genanvendelig kode, spare mig lidt tid, når jeg havde brug for at ændre nogle ting på koder, og på grund af dem er nogle opgaver meget lettere, end de burde være.

Hvis du ikke kan forstå, hvordan mønstrene fungerer her, er nogle gode indlæg om Strategi, Fabrik, Dekoratør og Adapter.

Ps: Hvis du kan lide dette indlæg, kan du dele det på Twitter, anbefale det på medium eller begge =). Dette hjælper mig virkelig med at nå ud til flere mennesker. Mange tak.