hur man börjar skriva ‘komplex’ kod

Detta är ett inlägg om att tänka på koden du skriver. Allt som finns här är min åsikt och du bör alltid överväga giltigheten av mina åsikter genom att jämföra dem med bättre! Språket Jag använder är Javascript. En förutsättning för att förstå denna artikel är att veta mellanliggande Javascript och förtrogenhet med vissa objektorienterade begrepp. Detta inlägg är inspirerat av kapitel 9 i Cristina Lopes utmärkta bok “övningar i programmeringsstil”.

ett riktigt vanligt mönster i kod är—

1. definiera ett enkelt objekt

var store_item = {
name : 'wonderball'
}

2. För att göra det klart att visas på en webbsida kör vi varje fastighet genom vissa funktioner.

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

och det är så vi ofta får data redo att visas. Nu när vår store_item har ett stort namn och ett utropstecken kan vi visa det på vår webbsida utan problem. Om det finns en tredje sak vi behöver göra skulle vi helt enkelt skriva en tredje funktion för att omvandla data och skicka objektet som vanligt.

det större, stora bildmönstret vi har skapat här är:

det finns några fina termer för denna typ av programmering som ‘procedur’ eller ‘imperativ’, men jag skulle kalla det en annan term: ‘enkel’. Det är mycket enkel programmering. Det är den typ av programmering som alla lär sig först. För program i liten skala är det absolut det bästa sättet att programmera, eftersom människor är bra på att följa var som helst från 1 till 10 logiska steg ganska bra.

när ditt program blir tillräckligt stort (över 10 transformationer innan data visas), eller en funktion ändrar många dataobjekt (mer än 2), eller vi har många IF-uttalanden som orsakar förgreningslogik, blir denna ‘enkla’ programmering istället ‘en röra’.

de flesta varje projekt eller kodstycke blir rörigt. Det mesta av programmeringen är faktiskt kodare som kommer på sätt att undvika att göra en röra, inte lösningar på det faktiska problemet med att visa data. Arbetet med programmering är att lära sig att skriva kod på ett sådant sätt att vi kan tillämpa 100-tals transformationer på 100-tals bitar av data och göra det ‘inte en enda röra’.

låt mig nu presentera dig för en stor förändring av mönstret ovan och överväga att det jag ska visa dig är det första steget att bli en mer avancerad kodare eftersom det bryter dig ur ‘enkel’ kodning. Det introducerar dig till nya sätt att tänka på hur man gör en enkel sak som att ändra vissa data för en webbsida. Objektet kommer nu att ha sin egen funktion som kallas ‘bind’, och den funktionen kommer att ansvara för att omvandla 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);

denna lösning beter sig precis som den ursprungliga ‘enkla’ koden ovan, men det verkar mer komplicerat, varför? För den enkla uppgiften vi har är det överkill, men vad är avvägningarna av denna komplexitet?

för att svara på det, låt oss prata om vad som är annorlunda:

1. vi har denna galna, konstig, ‘binda’ funktion, som tar som ett argument, inte ett nytt värde för namn, men i stället en annan funktion, säga Vad nu?
2. funktionerna kapitalisera och addExclamationPoint är olika, Nu ringer de inte item.name direkt längre.
3. vi ställer inte in namn med en ‘=’ längre, vi använder istället denna konstiga store_item.bind (function_name), syntax istället.

med dessa tre skillnader måste vi nu fråga oss, är denna förändring bättre? Kanske inte om projektet förblir så litet. Kanske ja om projektet blir mycket större.

nyckeländringen är att store_item-objektet nu är ansvarigt för att hantera dess tillstånd via bindningsfunktionen. Naturligtvis om du ville, du kan direkt ändra store_item.name, men objektet skriker praktiskt taget: “Hej, använd min bindningsfunktion för att ändra mig!”.

men nu är det lätt att se ett mönster där flera store_items var och en hanterar sin egen stat med sin 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öra 100 store_item s och hantera deras tillstånd är ganska lätt. Allt vi behöver göra är att skriva en funktion som bara har ett returvärde och använda vårt objekts .bind funktion.

magin i detta mönster Finns i bind-funktionen, så låt oss utforska det lite mer 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å där har du det, vi har gjort vår kod mer komplex, men nu har vi några nya fördelar:

1. ett objekt ändrar nu sin egen stat, och det kan göra det betydligt på bara en rad.
2. funktionerna vi har skrivit är renare, de ändrar inte objektegenskaper som i exemplet ovan, de tar bara en ingång och returnerar en utgång.
3. vi vet att när vi ändrar ett objekts tillstånd, kommer de funktioner vi använder förmodligen inte att ändra något annat objekts tillstånd av misstag

men vi har också några nackdelar:

1. din kod är definitivt mindre intuitiv för en ny comer nu.
2. för en liten webbplats är denna kod alltför komplex.

så vad är den slutliga domen, är det här sättet bättre? Värre? Mer förvirrande? (I början, ja.) Alla dessa frågor är öppna, men jag kan säga en sak säkert, att överväga och förstå mönster som detta är en del av att lära sig Javascript och växa som kodare. Att ständigt använda det’ enkla ‘ sättet att koda för att lösa problem blir ohållbart efter ett tag. Om du tar dig tid att lära sig mer ‘komplexa’ sätt att göra saker en hel del bra saker hända: din förmåga att tänka i sidled öppnar upp, Du kan läsa mer olika typer av kod, och du ökar de sätt du kan tänka på att lösa problem. Kanske är det den verkliga fördelen att lära sig detta och andra mönster.