Quais são os efeitos colaterais da programação, afinal?

Sempre que falamos sobre certos conceitos de programação, acho importante dar um passo para trás de quaisquer detalhes específicos que estamos discutindo e olhar para as coisas no contexto do quadro geral.

Alguns módulos apresentam efeitos colaterais; alguns não. Está bem.

Por exemplo, ontem toquei brevemente na ideia de programar efeitos colaterais, mas fiz isso ao falar sobre o uso de PSRs. E para aqueles que estão simplesmente interessados ​​em aspectos de programação em um sentido mais geral, é importante entendê-los também.

Lembre-se, a ideia de efeitos colaterais conforme declarado no PSR-1 é:

Um arquivo DEVE declarar novos símbolos (classes, funções, constantes, etc.) e não causar outros efeitos colaterais, ou DEVE executar lógica com efeitos colaterais, mas NÃO DEVE fazer as duas coisas.

Neste post, não estou tão interessado em discutir lógica com efeitos colaterais (porque há momentos em que os efeitos colaterais acontecem). Em vez disso, estou mais preocupado em entender os efeitos colaterais da programação (o que são, o que evitar e assim por diante).

Afinal, falar sobre efeitos colaterais em um contexto pode significar uma coisa enquanto, em programação, pode significar outra.

Efeitos colaterais de programação

Ok, então toda a ideia ou definição de um efeito colateral genérico é simples, certo?

um efeito secundário, tipicamente indesejável de uma droga ou tratamento médico.

Retire todo o aspecto do tratamento e você ficará com um “efeito secundário, … indesejável".

• optamos por incluir um arquivo,
• sabemos o que o arquivo faz,
• assim, se sabemos o que estamos incluindo e o que ele faz, como pode introduzir algo indesejável?

Pelo menos, é assim que muitas vezes ouço quando se trata de falar sobre efeitos colaterais. Na programação, sempre generalizei os efeitos colaterais como qualquer coisa que altere o estado do programa.

Fácil o suficiente, certo?

Efeitos colaterais no WordPress

Então digamos que você esteja trabalhando com WordPress, porque é sobre isso que eu faço e escrevo 🙂, e temos um arquivo que é responsável por adicionar um item de submenu a um dos menus de nível superior existentes.

Essa classe pode ser relativamente simples, pois envolve a chamada adequada da API do WordPress, é acionada quando anexada ao gancho [apropriado] e adiciona o submenu, conforme pretendido.

Mas digamos que essa classe, um método na classe ou incluindo um arquivo que essa classe também adiciona algum JavaScript ou estilos que alteram o estado do item do submenu de forma que seja destacado, ele se comporte como se tivesse sido "clicado" ou ele faz algo que o programa ou o usuário não pretende.

Isso seria um efeito colateral na medida em que altera o estado do programa.

O que o módulo deve fazer?

Essa classe em si deve fazer uma coisa :

O princípio de responsabilidade única é um princípio de programação de computador que afirma que cada módulo ou classe deve ter responsabilidade sobre uma única parte da funcionalidade fornecida pelo software, e essa responsabilidade deve ser inteiramente encapsulada pela classe.

Mas quando introduzimos algo que acrescenta ao que deveria fazer – quando aumentamos sua responsabilidade ou mudamos a única coisa que ele faz – então introduzimos um efeito colateral.

Lembre-se, isso não é inerentemente ruim (de acordo com a definição do PSR-1 acima), mas é importante reconhecer quando estamos fazendo isso e quando não estamos.

Então, como adicionamos funcionalidade?

Acho que a pergunta natural é que, se queremos adicionar funcionalidade a um programa que altera seu estado, como fazemos isso (e está errado)?

Primeiro, não, não é errado. Quero dizer, os programas têm estados diferentes com base em uma variedade de coisas, certo? Às vezes acontece quando algo é gravado em disco ou banco de dados; às vezes acontece quando o usuário clica em um elemento na interface do usuário e assim por diante.

Mas como esses estados acontecem é onde a natureza dos efeitos colaterais entra em jogo.

Tomemos, por exemplo, a ideia de um submenu. É suposto fazer uma coisa. Não deve alterar nada além do que vemos na tela.

• Ele não deve gravar no banco de dados,
• Ele não deve configurar um ouvinte de eventos para quando outro objeto adiciona um submenu,
• Não deve alterar a apresentação de nada fora de si mesmo.
• E assim por diante.

A adição de funcionalidade funciona da mesma maneira: você introduz classes que são responsáveis ​​por fazer uma coisa específica e as deixa fazer isso. Quando esses componentes trabalham em conjunto, você tem um programa funcional no qual cada módulo (classe/função/qualquer coisa) permanece em sua faixa, por assim dizer.

O que é uma regra prática?

Tenho certeza de que muitos de vocês que estão lendo isso têm sua opinião sobre quais são os efeitos colaterais e o que não são. E como você, eu tenho o meu.

Pense assim:

Se você chamar um método e ele retornar um valor e, em seguida, chamar um método novamente com o mesmo conjunto de dados, ele deverá retornar o mesmo valor.

É assim que você sabe que sua função, classe ou módulo genérico não tem efeitos colaterais.

E, como com qualquer coisa, cometi esses erros (e provavelmente continuarei), mas é uma questão de tentar melhorar em não fazê-lo.

Eventualmente, isso se tornará o novo normal.