Sådan begynder du at skrive ‘kompleks’ kode

dette er et indlæg om at tænke på den kode, du skriver. Alt indeholdt heri er min mening, og du bør altid overveje gyldigheden af mine meninger ved at sammenligne dem med bedre! Det sprog, jeg vil bruge, er Javascript. En forudsætning for at forstå denne artikel er at kende mellemliggende Javascript og fortrolighed med nogle objektorienterede koncepter. Dette indlæg er inspireret af kapitel 9 i Cristina Lopes’ fremragende bog “øvelser i programmeringsstil”.

et virkelig almindeligt mønster i kode er—

1. Definer et simpelt objekt

var store_item = {
name : 'wonderball'
}

2. Derefter kører vi hver ejendom gennem nogle funktioner for at gøre den klar til visning på en hjemmeside.

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.
}

og Sådan får vi ofte data klar til visning. Nu hvor vores store_item har et stort navn og et udråbstegn, kan vi vise det på vores hjemmeside ikke noget problem. Hvis der er en tredje ting, vi skal gøre, ville vi blot skrive en tredje funktion for at omdanne dataene og sende varen ind som normalt.

det større, Store billedmønster, vi har oprettet her, er:

der er et par smarte udtryk for denne type programmering, såsom ‘proceduremæssig’ eller ‘imperativ’, men jeg vil kalde det et andet udtryk: ‘enkel’. Det er meget simpelt programmering. Det er den type programmering, som alle lærer først. For programmer i lille skala er det absolut den bedste måde at programmere på, fordi mennesker er gode til at følge alt fra 1 til 10 logiske trin ganske godt.

når dit program bliver tilstrækkeligt stort (over 10 transformationer, før dataene vises), eller en funktion ændrer mange dataobjekter (mere end 2), eller vi har mange if-udsagn, der forårsager forgreningslogik, bliver denne ‘enkle’ programmering i stedet ‘et rod’.

de fleste hvert projekt eller stykke kode bliver rodet. Det meste af programmeringen er faktisk kodere, der kommer med måder at undgå at gøre rod, ikke løsninger på det faktiske problem med at vise dataene. Arbejdet med programmering er at lære at skrive kode på en sådan måde, at vi kan anvende 100-vis af transformationer på 100-vis af data og gøre det ‘ikke et rod’.

lad mig nu introducere dig til en stor ændring af mønsteret ovenfor og overveje, at det, jeg skal vise dig, er det første skridt til at blive en mere avanceret koder, fordi det bryder dig ud af ‘simpel’ kodning. Det introducerer dig til nye måder at tænke på, hvordan man gør en simpel ting som at ændre nogle data til en hjemmeside. Objektet vil nu have sin egen funktion kaldet ‘bind’, og denne funktion vil være ansvarlig for at transformere dataene.

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);

denne løsning opfører sig nøjagtigt som den originale ‘enkle’ kode ovenfor, men den virker mere kompleks, hvorfor? Fordi for den enkle opgave, vi har, er det overkill, men hvad er afvejningerne af denne kompleksitet?

for at svare på det, lad os tale om, hvad der er anderledes:

1. vi har denne skøre, underlige ‘bind’ – funktion, der tager som argument, ikke en ny værdi for navn, men i stedet en anden funktion, sig hvad nu?
2. funktionerne med stort og tilføjeklamationspunkt er forskellige, nu kalder de ikke item.name direkte længere.
3. vi sætter ikke navn med et ‘=’ længere, vi bruger i stedet dette underlige store_item.bind (function_name), syntaks i stedet.

med disse tre forskelle må vi nu spørge os selv, er denne ændring bedre? Måske ikke hvis projektet forbliver så lille. Måske ja, hvis projektet bliver meget større.

nøgleændringen er, at store_item-objektet nu er ansvarlig for at håndtere dets tilstand via bind-funktionen. Selvfølgelig, hvis du ville, du kunne direkte ændre store_item.name, men objektet skriger praktisk talt: “Hej, Brug Min bind-funktion til at ændre mig!”.

men nu er det nemt at se et mønster, hvor flere store_items hver styrer deres egen tilstand med deres egen .bind funktion:

// 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!

vi kan gøre 100 store_item s og styre deres tilstand er temmelig nemt. Alt, hvad vi skal gøre, er at skrive en funktion, der bare har en returværdi og bruge vores objekts .bind funktion.

magien i dette mønster er i bind-funktionen, så lad os undersøge det lidt mere nu.

// 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;
}

så der har du det, vi har gjort vores kode mere kompleks, men nu har vi et par nye fordele:

1. et objekt ændrer nu sin egen tilstand, og det kan gøre det betydeligt på kun en linje.
2. de funktioner, vi har skrevet, er renere, de ændrer ikke objektegenskaber som i eksemplet ovenfor, de tager bare et input og returnerer et output.
3. vi ved, at når vi ændrer et objekts tilstand, vil de funktioner, vi bruger, sandsynligvis ikke ændre noget andet objekts tilstand ved et uheld

men vi har også et par ulemper:

1. din kode er bestemt mindre intuitiv for en ny kommer nu.
2. for et lille sted er denne kode alt for kompleks.

så hvad er den endelige dom, er denne måde bedre? Værre? Mere forvirrende? (Først, ja .) Alle disse spørgsmål er åbne, men jeg kan sige en ting med sikkerhed, at overveje og forstå mønstre som dette er en del af at lære Javascript og vokse som en koder. Kontinuerlig brug af den’ enkle ‘ måde at kode på for at løse problemer bliver uholdbar efter et stykke tid. Hvis du tager dig tid til at lære mere ‘komplekse’ måder at gøre ting på, sker der mange gode ting: din evne til at tænke sideværts åbner op, du kan læse flere forskellige typer kode, og du øger måderne, du kan tænke på at løse problemer. Måske er det den virkelige fordel at lære dette og andre mønstre.