How To Start Writing ‘Complex’ Code

this is a post about thinking about the code you write. Tudo aqui contido é a minha opinião e você deve sempre considerar a validade das minhas opiniões comparando-as com as melhores! A linguagem que vou usar é Javascript. Um pré-requisito para entender este artigo é conhecer JavaScript intermediário e familiaridade com alguns conceitos orientados a objetos. Este post é inspirado no Capítulo 9 do excelente livro de Cristina Lopes “Exercises in Programming Style”.

um padrão realmente comum no código é—

1. definir um objecto simples

var store_item = {
name : 'wonderball'
}

2. Em seguida, para prepará-lo para exibir em uma página web, executamos cada propriedade através de algumas funções.

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

e é assim que frequentemente os dados são apresentados. Agora que nosso store_item tem um nome maiúsculo e um ponto de exclamação, podemos exibi-lo em nossa página Web sem problemas. Se houver uma terceira coisa que precisamos fazer nós simplesmente escreveríamos uma terceira função para transformar os dados, e passaríamos o item como de costume.

o padrão maior, grande imagem que criamos aqui é:

Há alguns fantasia termos para este tipo de programação, tais como ‘processual’, ou ‘imperativo’, mas eu diria que é um termo diferente: ‘simples’. É uma programação muito simples. É o tipo de programação que todos aprendem primeiro. Para programas de pequena escala, é absolutamente a melhor maneira de programar, porque os humanos são bons em seguir qualquer lugar de 1 a 10 passos lógicos muito bem.

quando o seu programa fica suficientemente grande (mais de 10 transformações antes de os dados serem exibidos), ou uma função está modificando um monte de objetos de dados (mais de 2), ou temos um monte de se declarações causando lógica de ramificação, esta programação ‘simples’ em vez disso torna-se ‘uma bagunça’.

a maioria dos projetos ou peças de código fica confuso. A maior parte da programação é, na verdade, programadores que vêm com maneiras de evitar fazer uma bagunça, não soluções para o problema real de exibir os dados. O trabalho de programação está em aprender a escrever código de tal forma que podemos aplicar 100’s de transformações em 100’s de pedaços de dados e torná-lo “não uma bagunça”.

agora, deixe-me apresentá-lo a uma grande mudança no padrão acima, e considere que o que estou prestes a mostrar-lhe é o primeiro passo para se tornar um codificador mais avançado, porque ele o liberta de codificação ‘simples’. Ele introduz você a novas formas de pensar sobre como fazer uma coisa simples como modificar alguns dados para uma página web. O objeto agora terá sua própria função chamada ‘bind’, e essa função será responsável por transformar os dados.

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

esta solução comporta-se exactamente como o código ‘simples’ original acima, mas parece mais complexo, porquê? Porque, para a tarefa simples que temos, é um exagero, mas quais são as contrapartidas desta complexidade?Para responder a isso, vamos falar do que é diferente .:

1. nós temos esta louca, estranha, função ‘bind’, que toma como argumento, não um novo valor para o nome, mas em vez de outra função, dizer o que agora?
2. as funções de capitalização e addExclamationPoint são diferentes, agora eles não chamam item.name directamente.
3. Nós não definimos o nome com um ‘=’ mais, nós em vez disso usamos este estranho store_item.bind (function_name), sintaxe em alternativa.

com estas três diferenças, agora temos que nos perguntar: esta mudança é melhor? Talvez não se o projecto continuar a ser tão pequeno. Talvez sim, se o projecto ficar muito maior.

a mudança de chave é que o objeto store_item é agora responsável por lidar com o seu estado através da função bind. Claro que se quisesses, podias alterar directamente store_item.name mas o objeto está praticamente gritando: “ei, use minha função de ligação para me mudar!”.

mas agora é fácil ver um padrão onde vários store_items cada um gerem o seu próprio estado com o seu próprio .função de ligação:

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

podemos fazer 100 andares e gerenciar o estado deles muito facilmente. Tudo o que temos que fazer é escrever uma função que apenas tem um valor de retorno e usar o nosso objeto .função bind.

a magia deste padrão está na função bind, então vamos explorar isso um pouco mais agora.

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

Então você tem isso, fizemos o nosso código mais complexo, mas agora nós temos alguns novos benefícios:

1. Um objeto agora, modifica-lo do próprio estado, e pode fazê-lo significativamente em apenas uma linha.
2. as funções que escrevemos são mais puras, eles não modificam propriedades de objetos como no exemplo acima, eles apenas tomam uma entrada e retornam uma saída.
3. sabemos que quando modificamos o estado de um objecto, as funções que usamos provavelmente não modificam o estado de qualquer outro objecto acidentalmente

mas também temos algumas desvantagens:

1. o seu código é definitivamente menos intuitivo para um novo cliente agora.
2. para um pequeno site, este código é excessivamente complexo.Então, qual é o juízo final, é assim melhor? Pior? Mais confuso? (No início, sim.) Todas estas perguntas estão abertas, mas eu posso dizer uma coisa com certeza, considerando e entendendo padrões como este é parte de aprender Javascript e crescer como codificador. A utilização contínua da forma “simples” de codificação para resolver problemas torna-se insustentável ao fim de algum tempo. Se você tomar o tempo para aprender formas mais “complexas” de fazer as coisas, muitas coisas grandes acontecem: sua capacidade de pensar lateralmente se abre, você pode ler tipos mais diversos de código, e você aumenta as maneiras que você pode pensar em resolver problemas. Talvez esse seja o verdadeiro benefício para aprender isso e outros padrões.