Designmønstre af tutorials - OOP's kraft (del 1)

Builder mønster - facetteret og flydende

Opdateret 2. oktober 2019, 02:10 AM GMT 5: 30+
Mange tak til Uran for denne fantastiske illustration!

Forudsætninger - Denne blogserie kræver et mellemliggende niveau af ekspertise inden for objektorienteret programmering. Du skal have grundlæggende viden om klasse, objekt, konstruktør, arv, værdi og referencetype. En mellemmand får viden, og eksperter vil skærpe sin viden ved at læse denne serie fra start til slut.

Designmønstre bruges til at repræsentere den bedste praksis, der er vedtaget af det erfarne objektorienterede softwareudviklerfællesskab.

Builder-designmønsteret hjælper os med at opbygge et objekt på en mere enklere og læselig måde. Builder-designmønsteret følger to enkle regler som nævnt nedenfor.

  1. Adskil den originale klasserepræsentation og dens konstruktionsmetoder.
  2. returnerer forekomsten af ​​klassen i det sidste trin

Det bedste eksempel på et builder-designmønster er SwiftUI, ja du læser rigtigt. SwiftUI bruger builder designmønster til de fleste af sine klasser, f.eks. Tekst, billede

Problem:

Tænk på klassen, siger Person, der har ti eller flere egenskaber, og afbilder dens konstruktørdesign, når du har brug for at oprette et eksempel på klassen Person. Dens konstruktør vil tage ti eller flere argumenter, det vil være svært at administrere disse mange argumenter som en enkelt funktion eller konstruktør, og til sidst mister du kodelæsbarheden. kassen nedenfor.

Prøv at køre ovenstående eksempel på legepladsen, det kører med succes og giver dig en forventet output. Logisk set er det korrekt.

Vi kan forbedre ovenstående eksempel ved at overvinde nedenstående punkter.

  1. Vi er nødt til at videregive værdierne i en nævnt rækkefølge, kan ikke omarrangere parametersekvensen for at forbedre læsbarheden.
  2. Vi er nødt til at videregive alle værdier, selvom vi ikke kender nogle værdier på tidspunktet for objektskabelse.

For eksempel. Antag, at du krævede at oprette et objekt i Person-klassen, men personen finder stadig et job. Når denne person tilslutter sig ethvert firma, er det kun vi, der har detaljer om arbejdet.

Opløsning:

  1. Opret logiske grupper af relaterede egenskaber.
  2. Opret separate builderklasser for forskellige grupper af egenskaber [hjælper med normalisering af egenskaber, dette er valgfrit].
  3. Hent et eksempel i det sidste trin.

Lad os forenkle dette med et eksempel,
Vi har allerede en klasse ved navn Person i eksempel WithoutDesignPatternExample1.swift, hvor vi har 14 egenskaber. Hvis vi nøje tjekker alle de 14 egenskaber, har egenskaberne 4 logiske grupper.

  1. Egenskaber for personlige oplysninger
  2. Kontaktoplysninger egenskaber
  3. Adresseoplysninger egenskaber
  4. Virksomhedsoplysninger ejendomme

Facetteret og flydende designmønster hjælper os sammen med at overvinde de to problemer, der er nævnt ovenfor.

I ovenstående eksempel har vi adskilt ansvarsklassen Personklasse i forskellige klasser. Personklasse har nu kun dataegenskaberne, mens vi har oprettet de flere builderklasser, der har ansvar for at opbygge / opdatere den relative gruppe af egenskaber.

Vi har en base builder klasse PersonBuilder og har fire flere afledte builder klasser navngivet PersonPersonalDetailsBuilder, PersonContactDetailsBuilder, PersonAddressDetailsBuilder og PersonCompanyDetailsBuilder.

Baseklassen PersonBuilder hjælper os med at skifte mellem flere bygherrer når som helst, mens andre fire bygherrer, der stammer fra PersonBuilder, har ansvar for at opdatere relative egenskaber.

I ovenstående eksempel kan vi tydeligt se, at konstruktionen af ​​et Person-objekt er mere læsbar sammenlignet med vores første eksempel WithoutDesignPatternExample1.swift, og vi kan også opdatere gruppen af ​​egenskaber eller en enkelt egenskab til enhver tid på en mere læselig måde.

I ovenstående eksempel skal du bemærke, at vi returnerer bygherreinstansen selv efter at have ringet til enhver ejendomsopdateringsmetode. Hvilket hjælper os med at skrive chaining af flere metoder til den samme builder i stedet for at skrive flere linjer hver for sig. Dette koncept er kendt som flydende mønster.

Fordele:

  1. Nem initialisering af et objekt i en klasse, der har for mange egenskaber på en mere læselig måde.
  2. Følger princippet om et enkelt ansvar.
  3. Initialiser objekt eller opdater egenskaber i enhver rækkefølge efter din bekvemmelighed.

Bonus:

For at gøre byggemønsteret konsistent på tværs af hele projektet kan du oprette protokol som nedenfor.

Kan du lide denne artikel?
Giv klapper og vis din støtte.
Det koster dig ikke noget at klappe.

Hvor skal jeg hen herfra?

Læs flere blogs fra min indeksside

Find mine lagre på Github
Følg mig på Twitter