Ontwerppatronen door zelfstudies— De kracht van OOP (deel 1)

Bouwerspatroon - gefacetteerd en vloeiend

Bijgewerkt op 2 oktober 2019, 02:10 AM GMT 5: 30+
Veel dank aan Uran voor deze geweldige illustratie!

Voorwaarden - Deze blogserie vereist een gemiddeld kennisniveau in objectgeoriënteerd programmeren. U moet basiskennis hebben over klasse, object, constructor, overerving, waarde en referentietype. Een intermediair zal kennis opdoen en experts zullen zijn of haar kennis aanscherpen door deze serie van begin tot eind te lezen.

Ontwerppatronen worden gebruikt om de best practices weer te geven die zijn aangenomen door de ervaren gemeenschap van objectgeoriënteerde softwareontwikkelaars.

Het ontwerppatroon van de bouwer helpt ons om een ​​object op een eenvoudiger en leesbare manier te bouwen. Het ontwerppatroon van de bouwer volgt twee eenvoudige regels zoals hieronder vermeld.

  1. Scheid de oorspronkelijke klassenrepresentatie en de constructiemethoden.
  2. retourneert het exemplaar van de klasse in de laatste stap

Het beste voorbeeld van een ontwerppatroon voor een bouwer is SwiftUI, ja je leest het goed. SwiftUI gebruikt het ontwerppatroon van de bouwer voor de meeste van zijn klassen, b.v. Tekst, afbeelding

Probleem:

Denk aan de klasse, bijvoorbeeld Persoon met tien of meer eigenschappen, die het constructorontwerp weergeeft wanneer u een instantie van de klasse Persoon moet maken. De constructor heeft tien of meer argumenten nodig, het zal moeilijk zijn om zoveel argumenten als een enkele functie of constructor te beheren en uiteindelijk verliest u de leesbaarheid van code. bekijk het onderstaande voorbeeld.

Probeer het bovenstaande voorbeeld in de speeltuin uit te voeren, het zal met succes worden uitgevoerd en u een verwachte uitvoer geven. Logisch gezien is het correct.

We kunnen het bovenstaande voorbeeld verbeteren door de onderstaande punten te overwinnen.

  1. We moeten de waarden in een genoemde volgorde doorgeven, kunnen de volgorde van parameters niet opnieuw rangschikken om de leesbaarheid te verbeteren.
  2. We moeten alle waarden doorgeven, zelfs als we sommige waarden niet weten op het moment dat het object wordt gemaakt.

Bijv. Stel dat u een object van de klasse Persoon moet maken, maar de persoon vindt nog steeds een baan. Wanneer die persoon bij welk bedrijf dan ook komt, hebben alleen wij werkdetails.

Oplossing:

  1. Maak logische groepen van gerelateerde eigenschappen.
  2. Maak afzonderlijke bouwklassen voor verschillende groepen met eigenschappen [helpt bij de normalisatie van eigenschappen, dit is optioneel].
  3. Ophalen van een instantie in de laatste stap.

Laten we dit vereenvoudigen met een voorbeeld,
We hebben al een klasse met de naam Persoon in bijvoorbeeld WithoutDesignPatternExample1.swift, waarin we 14 eigenschappen hebben. Als we alle 14 eigenschappen nauwkeurig controleren, hebben de eigenschappen 4 logische groepen.

  1. Persoonlijke gegevens eigenschappen
  2. Contactgegevens eigenschappen
  3. Adresgegevens eigenschappen
  4. Bedrijfsgegevens eigenschappen

Gefacetteerd en vloeiend ontwerppatroon samen helpt ons om de twee bovengenoemde problemen te overwinnen.

In het bovenstaande voorbeeld hebben we de verantwoordelijkheden van de Person-klasse in verschillende klassen gescheiden. Person class bevat nu alleen de data-eigenschappen, terwijl we de meerdere builder-klassen hebben gemaakt die verantwoordelijk zijn voor het bouwen / bijwerken van de relatieve groep eigenschappen.

We hebben één basisbuilderklasse PersonBuilder en hebben nog vier afgeleide builderklassen genaamd PersonPersonalDetailsBuilder, PersonContactDetailsBuilder, PersonAddressDetailsBuilder en PersonCompanyDetailsBuilder.

De basisklasse PersonBuilder helpt ons op elk moment te schakelen tussen meerdere bouwers, terwijl andere vier bouwers die zijn afgeleid van PersonBuilder verantwoordelijk zijn voor het bijwerken van relatieve eigenschappen.

In het bovenstaande voorbeeld kunnen we duidelijk zien dat de constructie van een Person-object beter leesbaar is in vergelijking met ons eerste voorbeeld WithoutDesignPatternExample1.swift. Ook kunnen we de groep met eigenschappen of een enkele eigenschap op elk gewenst moment op een beter leesbare manier bijwerken.

Merk in het bovenstaande voorbeeld op dat we de builderinstantie zelf retourneren na het aanroepen van elke methode voor het bijwerken van eigenschappen. Dat helpt ons om meerdere methoden van dezelfde builder te koppelen in plaats van meerdere regels afzonderlijk te schrijven. Dit concept staat bekend als vloeiend patroon.

Voordelen:

  1. Eenvoudig een object van een klasse met te veel eigenschappen op een leesbare manier initialiseren.
  2. Volgt het principe van één verantwoordelijkheid.
  3. Initialiseer object- of update-eigenschappen in willekeurige volgorde volgens uw gemak.

Bonus:

Om het bouwerspatroon consistent te maken in het hele project, kunt u een protocol maken zoals hieronder.

Vond je dit artikel leuk?
Geef claps en toon je steun.
Het kost je niets om te klappen.

Waar te gaan vanaf hier?

Lees meer blogs van mijn indexpagina

Vind mijn repositories op Github
Volg me op Twitter