Primero, leí un extracto del artículo de 1974 de Edsger W. Dijkstra "Sobre el papel del pensamiento científico":
Permíteme explicarte, lo que a mi gusto es característico de todo pensamiento inteligente. Es decir, que uno está dispuesto a estudiar en profundidad un aspecto del tema de forma aislada por el bien de su propia consistencia, todo el tiempo sabiendo que se está ocupando solo en uno de los aspectos. Sabemos que un programa debe ser correcto y podemos estudiarlo solo desde ese punto de vista; También sabemos que debería ser eficiente y podemos estudiar su eficiencia en otro día, por así decirlo. En otro estado de ánimo, podemos preguntarnos si, y si es así: por qué, el programa es deseable. Pero no se gana nada, por el contrario, abordando estos diversos aspectos simultáneamente. Es lo que a veces he llamado "la separación de preocupaciones", que, aunque no sea perfectamente posible, es la única técnica disponible para ordenar eficazmente los pensamientos, que yo sepa. Esto es lo que quiero decir con "centrar la atención en algún aspecto": no significa ignorar los otros aspectos, solo hace justicia al hecho de que, desde el punto de vista de este aspecto, el otro es irrelevante. Se trata de mentalidad de una y varias pistas simultáneamente.
Veo que la separación moderna de preocupaciones habla de modularizar su código. Sin embargo, al leer la cita anterior, entiendo esto como enfocar tu mente en una tarea en particular a la vez, sin enfocarme en otros aspectos. Esto no significa necesariamente que el código deba separarse en fragmentos modulares.
Es decir, digamos que hay un código frente a usted que en un archivo tiene los conceptos de vista, repositorio, controlador, manejo de eventos, fábrica, etc., todo en un solo archivo.
Para un breve ejemplo, aquí hay un código que tiene acceso a datos y vista (salida):
$sql = "SELECT * FROM product WHERE id = " . db_input($id);
$row = db_fetch_array(db_query($sql));
<option value="<?=$row['id']?>"<?= $row['ver'] == $row['ver'] ? ' selected="selected"' : '' ?>>Version <?=$row['ver']?></option>
Usando OO moderno, podría colocar el acceso a datos en su propio archivo usando el patrón de Repositorio, el código de Vista puede ir a su propia plantilla de archivo, y puedo conectarlos juntos para comunicarse a través de un controlador (o un Controlador de Acción o Solicitud), y puedo agregue una fábrica para crear y conectar varias dependencias. Y puedo tener un archivo de configuración que defina esas fábricas. Seguramente está a un paso de un solo archivo de todo.
Mi pregunta sobre la separación de preocupaciones es así: leyendo la cita de Dijkstra, tuve la idea de que tal vez no necesariamente significaba que la separación de preocupaciones era "separación modular de código (en archivos o sus propias funciones / métodos / etc.)", y que quería decir más para enfocar la mente en un aspecto del programa, sin agobiarte enfocándote en otros aspectos importantes pero aún no considerados, independientemente de si están físicamente separados en el código o no.
¿Por qué entonces nos estamos abrumando con la separación física del código modular y los patrones de diseño? ¿No será suficiente enfocarse solo en un aspecto, independientemente de cómo esté estructurado su código?
No estoy hablando de escribir el código de espagueti más horrible y luego solo considerar un aspecto del mismo, eso probablemente sería una carga. Pero al final, a lo que me dirijo es, ¿por qué realizar la separación del código físico, por qué dividir el código en archivos o fragmentos (métodos) separados, cuando no es necesario enfocarse mentalmente en un aspecto?
¿Debería la separación de preocupaciones seguir siendo un ejercicio mental, más que físico?
En otras palabras, ¿debería haber una desconexión entre los aspectos mentales (centrarse en) y físicos (código en papel) de la programación?
IF, WHILE, FORen lugar de GOTO. Modular = módulos con una API pública bien definida estrictamente separada de una implementación interna oculta y representación. (Por ejemplo, Modula, Mesa, Modula-2, Modula-3, luego dialectos Pascal ( UNIT).)