¿Qué son los efectos secundarios de la programación?

Cada vez que hablamos de ciertos conceptos de programación, creo que es importante dar un paso atrás en los detalles que estamos discutiendo y mirar las cosas en el contexto del panorama general.

Algunos módulos introducen efectos secundarios; algunos no. Está bien.

Por ejemplo, ayer mencioné brevemente la idea de programar efectos secundarios, pero lo hice al hablar sobre el uso de PSR. Y para aquellos que simplemente están interesados ​​en aspectos de la programación en un sentido más general, también es importante entenderlos.

Recuerde, la idea de los efectos secundarios como se establece en PSR-1 es:

Un archivo DEBERÍA declarar nuevos símbolos (clases, funciones, constantes, etc.) y no causar otros efectos secundarios, o DEBERÍA ejecutar lógica con efectos secundarios, pero NO DEBERÍA hacer ambas cosas.

En esta publicación, no estoy tan interesado en discutir la lógica con los efectos secundarios (porque hay momentos en los que ocurrirán efectos secundarios). En cambio, estoy más preocupado por comprender los efectos secundarios de la programación (qué son, qué evitar, etc.).

Después de todo, hablar de efectos secundarios en un contexto puede significar una cosa mientras que, en programación, puede significar otra.

Efectos secundarios de la programación

Bien, entonces la idea o definición de un efecto secundario genérico es simple, ¿ verdad?

un efecto secundario, típicamente indeseable, de un fármaco o tratamiento médico.

Elimina todo el aspecto del tratamiento y te quedas con un "efecto secundario… indeseable". Bueno, aquí está la parte potencialmente confusa:

• optamos por incluir un archivo,
• sabemos lo que hace el archivo,
• por lo tanto, si sabemos lo que estamos incluyendo y lo que hace, ¿cómo puede introducir algo indeseable?

Al menos, así es como a menudo escucho que me preguntan cuando se trata de efectos secundarios. En programación, siempre he generalizado los efectos secundarios como cualquier cosa que altere el estado del programa.

Bastante fácil, ¿verdad?

Efectos secundarios en WordPress

Entonces, digamos que está trabajando con WordPress, porque eso es lo que hago y escribo 🙂, y tenemos un archivo que es responsable de agregar un elemento de submenú a uno de los menús de nivel superior existentes.

Esa clase podría ser relativamente simple en el sentido de que envuelve la llamada adecuada de la API de WordPress, se activa cuando se adjunta al gancho [adecuado] y luego agrega el submenú, según lo previsto.

Pero digamos que esa clase, un método en la clase, o incluir un archivo que esa clase también agregue algo de JavaScript o estilos que alteren el estado del elemento del submenú de modo que esté resaltado, se comporte como si hubiera sido "clic" o hace algo que ni el programa ni el usuario pretenden.

Eso sería un efecto secundario en el sentido de que cambia el estado del programa.

¿Qué debe hacer el módulo?

Esa clase en sí debería hacer una cosa :

El principio de responsabilidad única es un principio de programación informática que establece que cada módulo o clase debe tener la responsabilidad sobre una sola parte de la funcionalidad proporcionada por el software, y esa responsabilidad debe estar completamente encapsulada por la clase.

Pero cuando introducimos algo que se suma a lo que se supone que debe hacer, cuando añadimos su responsabilidad o cambiamos el elemento central único que hace, entonces introducimos un efecto secundario.

Recuerde, esto no es intrínsecamente malo (según la definición de PSR-1 anterior), pero es importante reconocer cuándo lo estamos haciendo y cuándo no.

Entonces, ¿cómo agregamos funcionalidad?

Creo que la pregunta natural es que si queremos agregar funcionalidad a un programa que altera su estado, ¿cómo lo hacemos (y está mal)?

Primero, no, no está mal. Me refiero a que los programas tienen diferentes estados basados ​​en una variedad de cosas, ¿verdad? A veces sucede cuando se escribe algo en el disco o en una base de datos; a veces sucede cuando el usuario hace clic en un elemento de la interfaz de usuario, y así sucesivamente.

Pero cómo ocurren estos estados es donde entra en juego la naturaleza de los efectos secundarios.

Tomemos por ejemplo la idea de un submenú. Se supone que debe hacer una cosa. No debería alterar nada más que lo que vemos en la pantalla.

• No debería escribir en la base de datos,
• No debería configurar un detector de eventos para cuando otro objeto agrega un submenú,
• No debe alterar la presentación de nada fuera de sí mismo.
• Y así.

Agregar funcionalidad funciona de la misma manera: introduce clases que son responsables de hacer algo específico y les permite hacerlo. Cuando estos componentes funcionan en conjunto, entonces tiene un programa funcional en el que cada módulo (clase/función/lo que sea) permanece en su carril, por así decirlo.

¿Qué es una regla general?

Estoy seguro de que muchos de los que leen esto tienen su opinión sobre qué son y qué no son los efectos secundarios. Y como tú, tengo la mía.

Piénsalo de esta manera:

Si llama a un método y devuelve un valor, y luego vuelve a llamar a un método con el mismo conjunto de datos, debería devolver el mismo valor.

Así es como sabe que su función, clase o módulo genérico no tiene efectos secundarios.

Y, como con cualquier cosa, he cometido estos errores (y probablemente continúe), pero es cuestión de tratar de mejorar para no hacerlo.

Eventualmente, se convertirá en la nueva normalidad.