cum să începeți să scrieți cod ‘Complex’

acesta este un post despre gândirea codului pe care îl scrieți. Tot ceea ce conține aici este opinia mea și ar trebui să luați întotdeauna în considerare validitatea opiniilor mele comparându-le cu cele mai bune! Limba pe care o voi folosi este Javascript. O condiție prealabilă pentru înțelegerea acestui articol este cunoașterea JavaScript intermediar și familiarizarea cu unele concepte orientate pe obiecte. Această postare este inspirată din capitolul 9 din cartea excelentă a Cristinei Lopes “exerciții în stil de programare”.

un model foarte comun în cod este—

1. definiți un obiect simplu

var store_item = {
name : 'wonderball'
}

2. Apoi, să-l gata pentru a afișa pe o pagină web, vom rula fiecare proprietate prin intermediul unor funcții.

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

și acesta este modul în care primim adesea datele gata de afișare. Acum că store_item-ul nostru are un nume cu majuscule și un semn de exclamare, îl putem afișa pe pagina noastră web fără probleme. Dacă există un al treilea lucru pe care trebuie să-l facem, vom scrie pur și simplu o a treia funcție pentru a transforma datele și a trece elementul ca de obicei.

modelul de imagine mai mare pe care l-am creat aici este:

există câțiva termeni fanteziști pentru acest tip de programare, cum ar fi ‘procedural’ sau ‘imperativ’, dar l-aș numi un termen diferit: ‘simplu’. Este o programare foarte simplă. Este tipul de programare pe care toată lumea îl învață mai întâi. Pentru programele la scară mică, este absolut cel mai bun mod de a programa, deoarece oamenii sunt buni să urmeze oriunde de la 1 la 10 pași logici destul de bine.

când programul dvs. devine suficient de mare (peste 10 transformări înainte de afișarea datelor), sau o funcție modifică o mulțime de obiecte de date (mai mult de 2), sau avem o mulțime de declarații IF care cauzează logica de ramificare, această programare simplă devine în schimb o mizerie.

cele mai multe fiecare proiect sau bucată de cod devine murdar. Cea mai mare parte a programării este de fapt programatori care vin cu modalități de a evita să facă o mizerie, nu soluții la problema reală a afișării datelor. Munca de programare este în procesul de învățare pentru a scrie cod în așa fel încât să putem aplica 100 de transformări pe 100 de bucăți de date și să-l ‘nu o mizerie’.

acum, permiteți-mi să vă prezint o mare schimbare a modelului de mai sus și luați în considerare faptul că ceea ce vă voi arăta este primul pas pentru a deveni un coder mai avansat, deoarece vă rupe de codificarea simplă. Vă introduce noi modalități de gândire despre cum să faceți un lucru simplu, cum ar fi modificarea unor date pentru o pagină web. Obiectul va avea acum propria funcție numită ‘bind’, iar această funcție va fi responsabilă de transformarea datelor.

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

această soluție se comportă exact ca codul ‘simplu’ original de mai sus, dar pare mai complex, de ce? Pentru că pentru sarcina simplă pe care o avem, este excesivă, dar care sunt compromisurile acestei complexități?

pentru a răspunde la asta, să vorbim despre ce este diferit:

1. avem această funcție nebună, ciudată, ‘bind’, care ia ca argument, nu o nouă valoare pentru nume, ci o altă funcție, spune ce acum?
2. funcțiile majuscule și addExclamationPoint sunt diferite, acum nu apelează item.name direct mai.
3. nu mai setăm numele cu un’=’, în schimb folosim acest store_item ciudat.bind (nume_function), sintaxă în schimb.

cu aceste trei diferențe, acum trebuie să ne întrebăm, Este această schimbare mai bună? Poate că nu dacă proiectul rămâne atât de mic. Poate că da, dacă proiectul devine mult mai mare.

schimbarea cheie este că obiectul store_item este acum responsabil pentru gestionarea stării sale prin intermediul funcției bind. Desigur, dacă ai vrut, ai putea modifica direct store_item.name, dar obiectul țipă practic: “Hei, folosește funcția mea de legare pentru a mă schimba!”.

dar acum este ușor pentru a vedea un model în cazul în care mai multe store_items fiecare gestiona propria lor de stat cu propriile lor .funcția de legare:

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

putem face 100 store_item și de a gestiona starea lor destul de ușor. Tot ce trebuie să facem este să scriem o funcție care are doar o valoare returnată și să folosim Obiectul nostru .funcția de legare.

magia acestui model este în funcția de legare, așa că haideți să explorăm asta puțin mai mult acum.

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

deci, nu-l ai, ne-am făcut codul nostru mai complex, dar acum avem câteva beneficii noi:

1. un obiect modifică acum starea proprie și o poate face semnificativ într-o singură linie.
2. funcțiile pe care le-am scris sunt mai pure, nu modifică proprietățile obiectelor ca în exemplul de mai sus, ci doar iau o intrare și returnează o ieșire.
3. știm că atunci când modificăm starea unui obiect, funcțiile pe care le folosim probabil nu vor modifica accidental starea altui obiect

dar avem și câteva dezavantaje:

1. codul dvs. este cu siguranță mai puțin intuitiv pentru un nou venit acum.
2. pentru un site mic, acest cod este prea complex.

deci, care este judecata finală, este mai bine așa? Mai rău? Mai confuz? (La început, Da.) Toate aceste întrebări sunt deschise, dar pot spune un lucru sigur, luând în considerare și înțelegerea modelelor de acest gen face parte din învățarea Javascript și creșterea ca coder. Utilizarea continuă a modului simplu de codificare pentru rezolvarea problemelor devine nesustenabilă după un timp. Dacă vă faceți timp pentru a afla modalități mai complexe de a face lucruri se întâmplă multe lucruri grozave: capacitatea dvs. de a gândi lateral se deschide, puteți citi mai multe tipuri de cod și creșteți modurile în care vă puteți gândi la rezolvarea problemelor. Poate că acesta este adevăratul beneficiu pentru învățarea acestui model și a altor modele.