jak zacząć pisać “złożony” Kod

to jest post o myśleniu o kodzie, który piszesz. Wszystko co tu zawarte jest moim zdaniem i zawsze należy brać pod uwagę słuszność moich opinii porównując je do lepszych! Język, którego użyję, to Javascript. Warunkiem wstępnym do zrozumienia tego artykułu jest znajomość języka JavaScript pośredniego i znajomość niektórych pojęć obiektowych. Ten post jest zainspirowany rozdziałem 9 doskonałej książki Cristiny Lopes “ćwiczenia w stylu programowania”.

bardzo powszechnym wzorcem w kodzie jest—

1. Definiowanie prostego obiektu

var store_item = {
name : 'wonderball'
}

2. Następnie, aby przygotować ją do wyświetlenia na stronie internetowej, uruchamiamy każdą właściwość za pomocą niektórych funkcji.

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 tak często dostajemy dane gotowe do wyświetlenia. Teraz, gdy nasz store_item ma nazwę pisaną wielką literą i wykrzyknik, możemy bez problemu wyświetlić go na naszej stronie internetowej. Jeśli jest trzecia rzecz, którą musimy zrobić, po prostu napiszemy trzecią funkcję, która przekształci Dane i przekaże element jak zwykle.

większy, duży wzór obrazu, który tu stworzyliśmy, to:

istnieje kilka wymyślnych terminów dla tego typu programowania, takich jak “proceduralne” lub “imperatywne”, ale nazwałbym to innym terminem: “proste”. To bardzo proste programowanie. To rodzaj programowania, którego każdy uczy się pierwszy. W przypadku programów o małej skali jest to absolutnie najlepszy sposób programowania, ponieważ ludzie są dobrzy w wykonywaniu od 1 do 10 logicznych kroków.

kiedy twój program staje się wystarczająco duży (ponad 10 przekształceń przed wyświetlaniem danych), lub funkcja modyfikuje wiele obiektów danych (więcej niż 2), lub mamy wiele instrukcji IF powodujących logikę rozgałęziania, to “proste” programowanie staje się “bałaganem”.

większość projektów lub fragmentów kodu robi się niechlujna. Większość programowania to Programiści wymyślający sposoby na uniknięcie bałaganu, a nie rozwiązania rzeczywistego problemu wyświetlania danych. Praca programistyczna polega na nauce pisania kodu w taki sposób, że możemy zastosować 100 transformacji na 100 kawałkach danych i sprawić, że “nie będzie bałaganu”.

teraz pozwól, że przedstawię Ci dużą zmianę w powyższym wzorze i rozważ, że to, co zamierzam ci pokazać, jest pierwszym krokiem do stania się bardziej zaawansowanym koderem, ponieważ uwalnia cię od “prostego” kodowania. Wprowadza cię w nowe sposoby myślenia o tym, jak zrobić prostą rzecz, taką jak modyfikowanie niektórych danych na stronie internetowej. Obiekt będzie miał teraz swoją własną funkcję o nazwie “bind” i ta funkcja będzie odpowiedzialna za przekształcenie danych.

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

To rozwiązanie zachowuje się dokładnie jak oryginalny “prosty” kod powyżej, ale wydaje się bardziej złożone, dlaczego? Ponieważ w przypadku prostego zadania, które mamy, jest to przesada, ale jakie są kompromisy tej złożoności?

aby na to odpowiedzieć, porozmawiajmy o tym, co jest inne:

1. mamy tę szaloną, dziwną funkcję ‘bind’, która przyjmuje jako argument, nie nową wartość dla nazwy, ale zamiast tego inną funkcję, powiedz co teraz?
2. funkcje capitalize i addExclamationPoint są różne, teraz nie wywołują item.name już bezpośrednio.
3. Nie ustawiamy już Nazwy Z’=’, Zamiast tego używamy tego dziwnego store_item.bind (nazwa_funkcji), zamiast składni.

z tymi trzema różnicami, teraz musimy zadać sobie pytanie, czy ta zmiana jest lepsza? Może nie, jeśli projekt pozostanie tak mały. Może tak, jeśli projekt będzie znacznie większy.

zmiana klucza polega na tym, że obiekt store_item jest teraz odpowiedzialny za obsługę jego stanu za pomocą funkcji bind. Oczywiście, jeśli chcesz, możesz bezpośrednio zmienić store_item.name, ale obiekt praktycznie krzyczy: “Hej, Użyj mojej funkcji wiązania, aby mnie zmienić!”.

ale teraz łatwo jest zobaczyć wzorzec, w którym wiele store_items każdy zarządza własnym stanem za pomocą własnego.funkcja bind:

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

możemy zrobić 100 store_item i zarządzać ich stanem dość łatwo. Wszystko, co musimy zrobić, to napisać funkcję, która po prostu ma wartość zwracaną i użyć naszego obiektu .funkcja bind.

magia tego wzorca tkwi w funkcji bind, więc przyjrzyjmy się temu nieco bardziej.

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

więc masz to, zrobiliśmy nasz kod bardziej złożony, ale teraz mamy kilka nowych korzyści:

1. obiekt modyfikuje teraz swój własny stan i może to zrobić znacznie w jednej linii.
2. funkcje, które napisaliśmy, są czystsze, nie modyfikują właściwości obiektów, jak w powyższym przykładzie, po prostu pobierają dane wejściowe i zwracają dane wyjściowe.
3. wiemy, że kiedy modyfikujemy stan obiektu, funkcje, których używamy, prawdopodobnie nie zmienią przypadkowo stanu żadnego innego obiektu

ale mamy też kilka wad:

1. Twój kod jest teraz zdecydowanie mniej intuicyjny dla nowego użytkownika.
2. dla małej witryny ten kod jest zbyt złożony.

więc jaki jest Sąd Ostateczny, czy tak jest lepiej? Gorzej? Bardziej mylące? (Na początku tak.) Wszystkie te pytania są otwarte, ale mogę powiedzieć jedno na pewno, biorąc pod uwagę i rozumienie takich wzorców jest częścią nauki Javascript i rozwoju jako programista. Ciągłe używanie “prostego” sposobu kodowania do rozwiązywania problemów po pewnym czasie staje się niezrównoważone. Jeśli poświęcisz trochę czasu, aby dowiedzieć się więcej “złożonych” sposobów robienia rzeczy, wiele wspaniałych rzeczy się dzieje: twoja zdolność do myślenia w bok otwiera się, możesz przeczytać więcej różnych rodzajów kodu i zwiększyć sposoby myślenia o rozwiązywaniu problemów. Może to jest prawdziwa korzyść z uczenia się tego i innych wzorców.