Kuinka aloittaa “Kompleksikoodin” kirjoittaminen

tämä viesti käsittelee kirjoittamasi koodin miettimistä. Kaikki, mitä tässä on, on minun mielipiteeni,ja sinun pitäisi aina harkita mielipiteideni pätevyyttä vertaamalla niitä parempiin! Käytän Javascript-kieltä. Ennakkoedellytys ymmärtää tämän artikkelin on tietäen väli Javascript ja perehtyneisyys joitakin objekti-oriented käsitteitä. Tämä viesti on inspiroinut Luku 9 Cristina Lopes “Exercises in Programming Style”.

todella yleinen kuvio koodissa on—

1. Määrittele yksinkertainen objekti

var store_item = {
name : 'wonderball'
}

2. Sitten saada se valmis näyttämään verkkosivun, me ajaa jokaisen ominaisuuden kautta joitakin toimintoja.

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

ja näin saamme usein tiedot valmiiksi näytettäväksi. Nyt kun store_item on isolla nimellä ja huutomerkki, voimme näyttää sen sivuillamme ole ongelma. Jos on kolmas asia meidän täytyy tehdä, me yksinkertaisesti kirjoittaa kolmas toiminto muuttaa tietoja, ja siirtää kohteen kuten tavallista.

suurempi, iso kokonaiskuva jonka olemme luoneet tässä on:

tämäntyyppiselle ohjelmoinnille on olemassa muutamia hienoja termejä, kuten “menettelytapa” tai “imperatiivi”, mutta kutsuisin sitä erilaiseksi termiksi: “yksinkertainen”. Se on hyvin yksinkertaista ohjelmointia. Sen ohjelmoinnin jokainen oppii ensin. Pienimuotoisille ohjelmille se on ehdottomasti paras tapa ohjelmoida, koska ihmiset ovat hyviä seuraamaan missä tahansa 1-10 loogista askelta melko hyvin.

kun ohjelmasi saa riittävän suuren (yli 10 muunnosta ennen kuin data näytetään), tai funktio muokkaa paljon dataobjekteja (yli 2), tai meillä on paljon if-lausekkeita, jotka aiheuttavat haarautuvaa logiikkaa, tästä “yksinkertaisesta” ohjelmoinnista tulee sen sijaan “sotku”.

lähes jokainen projekti tai koodinpätkä saa sotkua. Suurin osa ohjelmoinnista on itse asiassa koodareita keksimässä tapoja välttää sotkua, ei ratkaisuja todelliseen datan näyttämisen ongelmaan. Työ ohjelmointi on oppia kirjoittamaan koodia siten, että voimme soveltaa 100: n muunnoksia 100: n tietojen palasia ja tehdä siitä “ei sotku”.

nyt, sallikaa minun esitellä teille suuri muutos yllä olevaan kaavaan, ja harkita, että mitä aion näyttää teille on ensimmäinen askel tulla kehittyneemmäksi koodaajaksi, koska se murtaa teidät ‘yksinkertaisesta’ koodauksesta. Se esittelee sinulle uusia tapoja ajatella, miten tehdä yksinkertainen asia, kuten muokkaamalla joitakin tietoja web-sivun. Oliolla on nyt oma funktio nimeltä “bind”, ja tämä funktio on vastuussa datan muuntamisesta.

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

tämä ratkaisu käyttäytyy aivan kuten alkuperäinen “yksinkertainen” koodi yllä, mutta vaikuttaa monimutkaisemmalta, miksi? Koska tämä yksinkertainen tehtävä, joka meillä on, on liioittelua, mutta mitkä ovat tämän monimutkaisuuden kompromissit?

vastatakseen, että puhutaan siitä, mikä on erilaista:

1. meillä on tämä hullu, outo, ‘sitoa’ funktio, joka ottaa argumenttina, Ei uusi arvo nimi, mutta sen sijaan toinen funktio, sanoa mitä nyt?
2. isolla-ja addExclamationPoint-funktiot ovat erilaisia, nyt ne eivät kutsu item.name suoraan enää.
3. emme enää aseta nimeä’=’, vaan käytämme tätä outoa store_itemiä.bind (function_name), syntaksi sijaan.

näiden kolmen eron myötä meidän on nyt kysyttävä itseltämme, onko tämä muutos parempi? Ehkä ei, jos hanke jää näin pieneksi. Ehkä kyllä, jos projekti paisuu.

keskeinen muutos on se, että store_item-Olio on nyt vastuussa tilansa käsittelystä bind-funktion kautta. Tietenkin, jos haluat, voit suoraan muuttaa store_item.name, mutta esine suorastaan huutaa: “Hei, käytä sidontatoimintoani muuttaaksesi minut!”.

mutta nyt on helppo nähdä kuvio, jossa useat store_itemit hallinnoivat kukin omaa tilaansa omillaan .sidontafunktio:

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

voimme tehdä 100 store_item ja hallita valtion melko helposti. Meidän tarvitsee vain kirjoittaa funktio, jolla on vain palautusarvo ja käyttää objektimme arvoa .sidontafunktio.

tämän kuvion taika on bind-funktiossa, joten Tutkitaanpa sitä nyt hieman lisää.

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

joten siinä se on, olemme tehneet koodistamme monimutkaisemman, mutta nyt meillä on muutamia uusia etuja:

1. objekti muokkaa nyt omaa tilaansa, ja se voi tehdä sen merkittävästi vain yhdellä rivillä.
2. kirjoittamamme funktiot ovat puhtaampia, ne eivät muuta objektin ominaisuuksia kuten yllä olevassa esimerkissä, ne vain ottavat tulon ja palauttavat tulosteen.
3. tiedämme, että kun muokkaamme olion tilaa, käyttämämme funktiot eivät todennäköisesti muuta minkään muun olion tilaa vahingossa

, mutta meillä on myös muutamia varjopuolia:

1. koodisi on ehdottomasti vähemmän intuitiivinen uudelle tulijalle nyt.
2. pienelle alueelle tämä koodi on liian monimutkainen.

joten mikä on lopullinen tuomio, onko näin parempi? Pahempaa? Sekavampaa? (Aluksi Kyllä.) Kaikki nämä kysymykset ovat avoimia, mutta voin sanoa yhden asian varmasti, harkitseminen ja ymmärtäminen malleja, kuten tämä on osa oppimista Javascript ja kasvaa koodarina. Jatkuva “yksinkertaisen” koodaustavan käyttäminen ongelmien ratkaisemiseksi muuttuu kestämättömäksi jonkin ajan kuluttua. Jos otat aikaa oppia enemmän ‘monimutkaisia’ tapoja tehdä asioita paljon hienoja asioita tapahtuu: kykysi ajatella laterally avautuu, voit lukea monipuolisempia koodeja, ja voit lisätä tapoja voit ajatella ongelmien ratkaisemiseksi. Ehkä se on todellinen hyöty tämän ja muiden kuvioiden oppimisesta.