hoe te beginnen met het schrijven van ‘complexe’ Code

Dit is een bericht over het nadenken over de code die u schrijft. Alles wat hierin staat is mijn mening en je moet altijd de geldigheid van mijn meningen overwegen door ze te vergelijken met betere! De taal die Ik zal gebruiken is Javascript. Een voorwaarde voor het begrijpen van dit artikel is te weten intermediate Javascript en vertrouwdheid met een aantal object-georiënteerde Concepten. Dit bericht is geïnspireerd op hoofdstuk 9 van Cristina Lopes ‘uitstekende boek” oefeningen in programmeerstijl”.

een veel voorkomend patroon in code is—

1. Definieer een eenvoudig object

var store_item = {
name : 'wonderball'
}

2. Om het vervolgens klaar te krijgen om op een webpagina weer te geven, draaien we elke eigenschap door een aantal functies.

addExclamationPoint(store_item);
capitalizeName(store_item);function addExclamationPoint(item) {
item.name = item.name + '!';
}function capitalizeName(item) {
// some code to capitalize item.name, cut out for brevity.
}

en zo krijgen we vaak gegevens klaar om weer te geven. Nu onze store_item een naam met hoofdletters en een uitroepteken heeft, kunnen we deze zonder problemen op onze webpagina weergeven. Als er een derde ding is dat we moeten doen, schrijven we gewoon een derde functie om de gegevens te transformeren, en geven het item door zoals gewoonlijk.

het grotere, grotere beeldpatroon dat we hier hebben gemaakt is:

er zijn een paar mooie termen voor dit soort programmering, zoals ‘procedureel’, of’ imperatief’, maar ik zou het een andere term noemen:’eenvoudig’. Het is heel eenvoudig programmeren. Het is het soort programmering dat iedereen als eerste leert. Voor programma ‘ s op kleine schaal is het absoluut de beste manier om te programmeren, omdat mensen goed zijn in het volgen van 1 tot 10 logische stappen heel goed.

als uw programma voldoende groot wordt (meer dan 10 transformaties voordat de gegevens worden weergegeven), of als een functie veel gegevensobjecten wijzigt (meer dan 2), of als er veel IF-statements zijn die vertakkingslogica veroorzaken, wordt deze ‘eenvoudige’ programmering in plaats daarvan ‘een puinhoop’.

bijna elk project of stuk code wordt rommelig. Het grootste deel van programmeren is eigenlijk programmeurs bedenken manieren om te voorkomen dat het maken van een puinhoop, niet oplossingen voor het werkelijke probleem van het weergeven van de gegevens. Het werk van programmeren is het leren om code te schrijven op zo ‘n manier dat we 100’s transformaties kunnen toepassen op 100’ S stukjes data en het ‘geen puinhoop’ maken.

Nu, Laat me u voorstellen aan een grote verandering in het patroon hierboven, en bedenk dat wat ik op het punt om u te laten zien is de eerste stap om een meer geavanceerde coder omdat het breekt je uit van ‘eenvoudige’ codering. Het introduceert u nieuwe manieren van denken over hoe je een eenvoudig ding te doen, zoals het wijzigen van een aantal gegevens voor een webpagina. Het object zal nu zijn eigen functie hebben, genaamd ‘bind’, en die functie zal verantwoordelijk zijn voor het transformeren van de data.

var store_item = {
name: 'wonderball',
bind: function(func) {
this.name = func(this.name);
return this;
}
}// Here are two functions I'll use to transform the store_item.name, each one now just takes a name and modifies it, neither function has any clue what properties it's changing in store_item anymore.function capitalize(name) {
return name.replace(/\w\S*/g, function(txt) {
return txt.charAt(0).toUpperCase() +
txt.substr(1).toLowerCase();
});
}function addExclamationPoint(name) {
return name + '!';
}store_item.bind(addExclamationPoint).bind(capitalize);

deze oplossing gedraagt zich precies zoals de oorspronkelijke ‘eenvoudige’ code hierboven, maar het lijkt complexer, waarom? Want voor de eenvoudige taak die we hebben, is het overkill, maar wat zijn de afwegingen van deze complexiteit?

om dat te beantwoorden, laten we het hebben over wat er anders is:

1. We hebben deze gekke, vreemde, ‘bind’ functie, die als argument gebruikt, niet een nieuwe waarde voor naam, maar in plaats daarvan een andere functie, zeg wat nu?
2. de functies hoofdletter en addExclamationPoint zijn verschillend, nu roepen ze geen item.name direct meer.
3. we zetten de naam niet meer in met een’=’, We gebruiken in plaats daarvan dit rare store_item.bind (function_name), syntaxis in plaats daarvan.

met deze drie verschillen, moeten we ons nu afvragen, is deze verandering beter? Misschien niet als het project zo klein blijft. Misschien wel als het project veel groter wordt.

de belangrijkste verandering is dat het store_item object nu verantwoordelijk is voor het afhandelen van zijn status via de bind functie. Natuurlijk, als je wilt, kun je direct veranderen store_item.name maar het object schreeuwt bijna: “hé, gebruik mijn bindfunctie om me te veranderen!”.

maar nu is het gemakkelijk om een patroon te zien waar meerdere store_items elk hun eigen status beheren met hun eigen .bind functie:

// Three store items, each one with a different state.store_item1.bind(addExclamationPoint).bind(capitalize); //Wonderball!store_item2.bind(capitalize);
//Wonderballstore_item3.bind(addExclamationPoint);
//wonderball!

we kunnen 100 store_item ‘ s maken en hun staat vrij gemakkelijk beheren. Het enige wat we moeten doen is een functie schrijven die gewoon een retourwaarde heeft en die van ons object gebruiken .bind functie.

de magie van dit patroon zit in de bind-functie, dus laten we dat nu wat meer onderzoeken.

// 1. First define the function, and have it take as an argument another function. Taking a function as an argument, instead of data is the core change here. bind: function(func) { // 2. This second line is the secret sauce, it will run the function you passed in with 'this.name' as an argument, and then assign whatever value is returned to this.name. Mull this over. this.name = func(this.name);// 3. Finally, return 'this'. You don't have to have this step in here, but returning 'this' is what allows .bind chainging to happen (.e.g. doing .bind().bind() vs .bind(); .bind();) return this;
}

dus daar heb je het, we hebben onze code complexer gemaakt, maar nu hebben we een paar nieuwe voordelen:

1. een object wijzigt nu zijn eigen toestand, en het kan het aanzienlijk doen in slechts één regel.
2. de functies die we hebben geschreven zijn zuiverder, ze wijzigen geen objecten eigenschappen zoals in het voorbeeld hierboven, ze nemen gewoon een invoer en retourneren een uitvoer.
3. we weten dat wanneer we de status van een object wijzigen, de functies die we gebruiken waarschijnlijk niet per ongeluk de status van een ander object wijzigen

maar we hebben ook een paar nadelen:

1. uw code is nu zeker minder intuïtief voor een nieuwe bezoeker.
2. voor een kleine site is deze code te complex.

dus wat is het uiteindelijke oordeel, is dit veel beter? Erger? Meer verwarrend? (In het begin, ja.) Al deze vragen zijn open, maar ik kan een ding zeker zeggen, overwegen en begrijpen van patronen als dit is onderdeel van het leren van Javascript en groeien als een coder. Het voortdurend gebruiken van de’ eenvoudige ‘ manier van coderen om problemen op te lossen wordt na een tijdje onhoudbaar. Als je de tijd neemt om meer ‘complexe’ manieren te leren om dingen te doen, gebeuren er veel geweldige dingen: je vermogen om lateraal te denken opent zich, Je kunt meer verschillende soorten code lezen, en je verhoogt de manieren waarop je kunt denken over het oplossen van problemen. Misschien is dat het echte voordeel om dit en andere patronen te leren.