По-перше, я прочитав уривок статті Едсгера У. Дійкстри 1974 року "Про роль наукової думки":
Дозвольте спробувати пояснити вам, що на мій смак характерне для всього розумного мислення. Це полягає в тому, що хтось готовий поглиблено вивчити аспект предмета своєї людини ізольовано заради власної послідовності, увесь час знаючи, що людина займається лише одним із аспектів. Ми знаємо, що програма повинна бути правильною, і ми можемо вивчати її лише з цієї точки зору; ми також знаємо, що це повинно бути ефективним, і ми можемо вивчити його ефективність в інший день, так би мовити. В іншому настрої ми можемо запитати себе, і якщо так: чому, програма бажана. Але нічого не отримується - навпаки! - одночасно вирішуючи ці різні аспекти. Це те, що я іноді називаю "відокремленням проблем", яке, навіть якщо не цілком можливо, поки що є єдиною доступною технікою ефективного упорядкування думок, про яку я знаю. Це те, що я маю на увазі під "зосередженням уваги на якомусь аспекті": це не означає ігнорування інших аспектів, це просто справедливість у тому, що з точки зору цього аспекту, інше не має значення. Це однозначне та багатоколірне налаштування одночасно.
Я бачу сучасне розділення проблем, що говорять про модуляцію вашого коду. Однак, читаючи цитату вище, я розумію це як зосередження свого розуму на одному конкретному завданні, але не зосереджене на інших аспектах. Це для мене не означає, що код потрібно розділяти на модульні шматки.
Тобто, скажімо, перед вами є код, який в одному файлі містить поняття перегляду, сховища, контролера, обробки подій, фабрики тощо, всі в одному файлі.
Короткий приклад, ось код, який має доступ до даних та перегляд (вихід):
$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>
Використовуючи сучасний OO, я міг розмістити доступ до даних у своєму власному файлі за допомогою шаблону сховища, код View може перейти до власного шаблону файлу, і я можу з'єднати їх разом для спілкування через контролер (або Action або Request Handler), і я можу додайте фабрику для створення та підключення різних залежностей. І я можу мати файл конфігурації, який визначає ці заводи. Звичайно, це крок від єдиного файлу.
Моє запитання про розділення проблем так: читаючи цитату Дійкстра, я зрозумів, що, можливо, він не обов'язково мав на увазі, щоб розділення проблем було "модульним розділенням коду (на файли або їх власні функції / методи / тощо)", і що він мав на увазі більше, щоб зосередити свою увагу на аспекті програми, не обтяжуючи себе зосередженням інших важливих, поки не розглянутих аспектів, незалежно від того, фізично вони розділені в коді, чи ні.
Чому тоді ми обтяжуємо себе фізичним модульним розділенням коду та моделями дизайну? Чи буде недостатньо просто зосередитись на аспекті, незалежно від того, як структурований ваш код?
Я не говорю про написання найстрашнішого коду спагетті, а потім лише розгляд його аспекту, це, ймовірно, буде тягарем. Зрештою, до чого я йду, це, навіщо виконувати розділення фізичного коду, навіщо розділяти код на відокремлені файли або фрагменти (методи), коли ментально зосередитись на аспекті не потрібно?
Чи повинен розлучення проблем залишатися розумовою вправою, а не фізичною?
Іншими словами, чи повинен бути розрив між психічним (фокус на) та фізичним (кодом на папері) аспектами програмування?
IF, WHILE, FORа GOTO. Модульний = модулі з чітко визначеним загальнодоступним API, чітко відокремлений від прихованої внутрішньої реалізації та подання. (Наприклад Modula, Mesa, Modula-2, Modula-3, пізніші діалекти Паскаля ( UNIT).)