Share
Als het gaat om ontwerppatronen, hebt u mogelijk vragen:
Waarom zouden we ontwerppatronen moeten gebruiken bij het programmeren? Onze code kan prima werken zonder deze code.
Mijn tegenvraag zou dan zijn: "Woon je liever in een luxueus huis, of in een eenvoudig etablissement met vier muren?" Beide dienen immers ons doel.
Over het algemeen gaan we op zoek naar een luxe huis omdat het betere faciliteiten biedt en minder onderhoud vereist, en het onderhoud kan worden gedaan met minder gedoe omdat het basiswerk er al is.
Hetzelfde geldt voor programmeren: een code met ontwerppatronen is gemakkelijk te begrijpen, gemakkelijk te onderhouden en eenvoudig uit te breiden.
In deze reeks tutorials behandelen we enkele verschillende ontwerppatronen die beschikbaar zijn voor ons in de programmering. Je leert over hun voor- en nadelen en factoren die aangeven waar we ze moeten gebruiken.
In deze tutorials zal ik PHP als basistaal gebruiken om ontwerppatronen te demonstreren; ze zijn echter in feite een concept dat op elke programmeertaal kan worden toegepast - het is gewoon een kwestie van de syntaxis wijzigen volgens de taal van uw voorkeur.
Ontwerpregels zijn verdeeld in vier categorieën:
In deze tutorial gaan we het ontwerppatroon van de gevel behandelen. Het valt onder de categorie structurele patronen omdat het gaat over hoe uw code moet worden gestructureerd om het gemakkelijk begrijpbaar te maken en het goed onderhouden op de lange termijn te houden.
Stel dat u enkele bewerkingen achter elkaar uitvoert en dat dezelfde actie op meerdere plaatsen in uw toepassing vereist is. Je moet dezelfde code keer op keer op verschillende plaatsen plaatsen. Dat heb je gedaan, maar na een paar dagen merk je dat er iets moet worden veranderd in die code.
Zie je het probleem? We moeten de wijzigingen aanbrengen op alle plaatsen waar de code bestaat. Het is pijnlijk, nietwaar?
Als oplossing moet u een leadcontroller maken die alle herhalingscode verwerkt. Vanuit het oogpunt van bellen zullen we alleen de hoofdcontroller bellen om acties uit te voeren op basis van de opgegeven parameters.
Als we nu wijzigingen in het proces moeten aanbrengen, hoeven we alleen maar de leadcontroller te wijzigen in plaats van de wijziging op alle plaatsen aan te brengen waar we die code hebben gebruikt.
Laten we in deze zelfstudie één les kiezen zodat deze leesbaarder wordt. Laten we zeggen dat je een taak hebt gekregen om het huwelijk van je vriend te plannen. Als je alles alleen doet, stel je dan de dingen voor die je moet bedekken. Het creëert een grotere kans op fouten en vergroot de kans op het missen van iets dat de bruiloft van je vriend drastisch kan beïnvloeden.
In dit geval, in plaats van alles alleen te doen, moet u een weddingplanner gebruiken en ervoor zorgen dat de klus op een goed beheerde manier wordt gedaan met minder kans op een fout.
Hier gedraag je je als een cliënt die het proces initieert, en de weddingplanner werkt als een "façade" voor jou, en voltooit de taak op basis van jouw richting.
In deze sectie zullen we nog een voorbeeld zien, wat heel gebruikelijk is voor websites, natuurlijk met een codevoorbeeld. We zullen een implementatie van het ontwerppatroon van de gevel zien met behulp van een productcontroleproces. Maar laten we, voordat we de perfecte code met het gevelpatroon controleren, eens naar een code kijken die een probleem heeft.
Een eenvoudig betalingsproces omvat de volgende stappen:
// Simple CheckOut Process $ productID = $ _GET ['productId']; $ qtyCheck = new productQty (); if ($ qtyCheck-> checkQty ($ productID)> 0) // Product aan winkelwagen toevoegen $ addToCart = new addToCart ($ productID); // Bereken verzendkosten $ shipping = new shippingCharge (); $ Verzend-> updateCharge (); // Bereken korting op basis van $ korting = nieuwe korting (); $ Korting-> applyDiscount (); $ order = nieuwe bestelling (); $ Order-> generateOrder ();
In de bovenstaande code ziet u dat de betalingsprocedure verschillende objecten bevat die moeten worden geproduceerd om de betaalhandeling te voltooien. Stel je voor dat je dit proces op meerdere plaatsen moet implementeren. Als dat het geval is, zal het problematisch zijn wanneer de code moet worden gewijzigd. Het is beter om die wijzigingen op alle plaatsen tegelijk aan te brengen.
We zullen hetzelfde schrijven met het gevelpatroon, waardoor dezelfde code beter onderhouden en uitgebreid kan worden.
class productOrderFacade public $ productID = "; public function __construct ($ pID) $ this-> productID = $ pID; public function generateOrder () if ($ this-> qtyCheck ()) // Product aan winkelwagen toevoegen $ this-> addToCart (); // Verzendkosten berekenen $ this-> calulateShipping (); // Bereken korting als $ this-> applyDiscount (); // Plaats en bevestig Order $ this-> placeOrder (); private functie addToCart () / * ... product toevoegen aan winkelwagen ... * / persoonlijke functie qtyCheck () $ qty = 'verkrijg producthoeveelheid uit database'; if ($ qty> 0) return true; else ga terug true; persoonlijke functie calulateShipping () $ shipping = new shippingCharge (); $ shipping-> calculateCharge (); private function applyDiscount () $ discount = new discount (); $ discount-> applyDiscount (); private function placeOrder () $ order = nieuwe volgorde (); $ order-> generateOrder ();
Vanaf nu hebben we onze productorder gevel klaar. Het enige wat we moeten doen is het gebruiken met een paar communicatiekanalen met code, in plaats van een stel code zoals uitgedrukt in het vorige deel.
Controleer het aantal code hieronder dat u moet investeren om een betaalproces op meerdere posities te hebben.
// Opmerking: we moeten directe get-waarden voor databasequery's niet gebruiken om SQL-injectie $ productID = $ _GET ['productId'] te voorkomen; // Alleen 2 regels code op alle plaatsen, in plaats van een langdurig proces overal $ order = new productOrderFacade ($ productID); $ Order-> generateOrder ();
Stel je nu voor wanneer je wijzigingen moet aanbrengen in je betaalproces. Nu maakt u eenvoudig wijzigingen aan in de gevelklasse die we hebben gemaakt, in plaats van wijzigingen aan te brengen op elke plaats waar deze is toegepast.
Eenvoudig gesteld kunnen we zeggen dat het gevelpatroon moet worden uitgevoerd in een situatie waarin u één interface nodig hebt om meerdere procedures te voltooien, zoals in het voorbeeld van de weddingplanner die als een gevel voor u werkt om meerdere procedures te voltooien.
Laat eventuele opmerkingen of vragen achter in de feed.
Accentsconagua