Учитель: У тебя есть 4 яблока, половину ты отдал другу. Сколько у тебя осталось?
Ученик: Три с половиной
Я уже писал о “дьяволе в деталях”. В той заметке. я сделал вывод: чтобы не было дьявола в деталях, нужно продумывать устройство (структуру, архитектуру) — ангел в устройстве. Но я не переставал об этом думать, да и фраза достаточно часто звучит в ИТ-кругах.
Фраза меня задевала, потому что обычно она звучит как “универсальная отмазка” — это не мы виноваты, это, он, гад, залез в детали.
Давайте отбросим эмоции (которые всегда есть в этой фразе) и посмотрим в суть. О чем собственно речь: о том, что есть некая “деталь”, обычно не замеченная изначально, которая существенно влияет на решение задачи.
Вспомнив, что все мы, хотя бы немного, математики, назовем правильно эту “деталь” — это часть условия задачи. Не знаю, как вы, а я в этом месте вздыхаю с облегчением. Так вот в чем дело, просто в ходе работы изменилось условие задачи. Очевидно, что если условие задачи изменилось, то и решение должно измениться.
Как правило, мы решаем задачи с неполными, нечеткими, неверно понятыми (см. эпиграф) или меняющимися по ходу условиями (см. фото). Полагаю, что это следствие “детского возраста” ИТ (“детские болезни”). Может быть, отрасль повзрослеет, но пока мы живем в условиях меняющихся условий :).
Как в них жить? Так как мы всегда заранее знаем, что условие задачи будет меняться по ходу разработки, мы должны быть к этому готовыми. Способы нам известны:
- прототипирование
- гибкая архитектура
- точки расширения
- компоненты
- гибкие процессы
- и так далее
Главное, что теперь, я точно знаю как переводится фраза “дьявол в деталях”: “мы облажались, потому что заранее не подумали о том, как будет меняется наша система при изменении условий”.
Постоянная ссылка
Есть два прямо противоположных параметра: жёсткость и гибкость.
Жёсткость определяется числом зацеплений компонентов.
Гибкость определяется как мало придётся затронуть связей, чтобы отцепить один компонент и прицепить другой.
В этом смысле динамические языки не обладают жёсткостью, а статические — гибкостью.
Но! Есть КОП!)) Абсолютно жёсткие кирпичики с неизменяемым интерфейсом, но кирпичиков много, кирпичики легко изменять и тестировать в силу их малого размера))
Практически идеальный пример КОП (имхо) — Компонентный Паскаль))
Постоянная ссылка
Не очень понимаю, какое отношение имеет «жесткость и гибкость» к моему тексту…
Но вот Компонентный Паскаль, на мой взгляд, имеет очень малое отношение к (нужному мне) сборочному программированию и к повторному использованию (reuse). И основная причина — жесткость связей между модулями и иерархия (наследование). Впрочем, я об этом уже несколько раз писал.
Постоянная ссылка
Эммм… Жёсткость связей не такая уж и большая. Например, базовый кирпичик — если расширяет интерфейс, но не трогает существующий — ничего страшного не произойдёт. Что касается наследования, то здесь рецепт прост, и я соглашусь, что Go — уже что-то похожее на правду (ведь прямой предок Оберон). Его система интерфейсов и утиная типизация — делают своё дело в больших системах. В этом смысле, Компонентный Паскаль не запрещает наследоваться от полностью абстрактного типа с описанными и зафиксированными методами. Что, по сути — и есть общий базовый универсальный интерфейс)) Строго говоря, Именно наследование всех от абстрактного класса и композиция, а не наследование — официальные рекомендации по построению программных систем в КП.