Unix way гласит: "Write small simple things that do one thing well". Интересна мне не сама постановка, а то, к чему привести может следование этому пути. В компост можно добавить также слова Robert C. Martin'а: "Functions should do one thing. They should do it well. They should do it only."
Сначала об очевидном. Программа, как система - традиционно сложное изваяние, исправлять недостатки которой затруднительно, добавлять новые функции тем паче. Как вариант можно разбить программу на маленькие составляющие, каждая из которых имеет свою сферу ответственности. Встаёт вопрос: "А как осуществлять взаимодействие разрозненных частей?"
Тестирование. В современных методологиях разработки программного обеспечения этот пункт ключевой, даже опорный. Тестировать проще маленькие модули. Причём, особое значение приобретают зависимости между модулями: что если они кольцевые? Такого нужно избегать; даже ценой полной переработки (рефакторинга). Функционально законченные модули - это хорошо. В идеале зависимости должны иметь односторонний характер (если рассматривать всю систему, то структура её приобретёт вид направленного ацикличного графа). Можно даже аналогию провести, например, с простой арифметической последовательностью действий: 1 + (4-6*7) - на самом низком уровне будет расположено умножение; выше - вычитание; наверху - сложение. Если это изобразить на листе бумаги, получится древовидная карта вычисления. Наподобие этой карты будет выглядеть эталонная архитектура программы. Кстати замечу, что "unix way" тут раскроется во всей красе.
Оценка сложности. Оценку модулей (особенно самых мелких вариантов) производить, во-первых, не затруднительно, а во-вторых, актуально - точность будет на уровне. Декомпозиция сложной системы на мелкие - анализ - даст хорошие результаты, ошибки будут минимальные.
Вопрос. Хорошо ли соотносится модульная структура с парадигмой ООП? Пакеты, модули, классы, методы (классов) подходят к "unix way"? Речь не идёт о множестве программ (уже готовых) и их объединении, речь идёт о разработке конкретной программы и подходе к разработке (деление на модули, слои, уровни, модели, контроллеры, etc.).
Сначала об очевидном. Программа, как система - традиционно сложное изваяние, исправлять недостатки которой затруднительно, добавлять новые функции тем паче. Как вариант можно разбить программу на маленькие составляющие, каждая из которых имеет свою сферу ответственности. Встаёт вопрос: "А как осуществлять взаимодействие разрозненных частей?"
Тестирование. В современных методологиях разработки программного обеспечения этот пункт ключевой, даже опорный. Тестировать проще маленькие модули. Причём, особое значение приобретают зависимости между модулями: что если они кольцевые? Такого нужно избегать; даже ценой полной переработки (рефакторинга). Функционально законченные модули - это хорошо. В идеале зависимости должны иметь односторонний характер (если рассматривать всю систему, то структура её приобретёт вид направленного ацикличного графа). Можно даже аналогию провести, например, с простой арифметической последовательностью действий: 1 + (4-6*7) - на самом низком уровне будет расположено умножение; выше - вычитание; наверху - сложение. Если это изобразить на листе бумаги, получится древовидная карта вычисления. Наподобие этой карты будет выглядеть эталонная архитектура программы. Кстати замечу, что "unix way" тут раскроется во всей красе.
Оценка сложности. Оценку модулей (особенно самых мелких вариантов) производить, во-первых, не затруднительно, а во-вторых, актуально - точность будет на уровне. Декомпозиция сложной системы на мелкие - анализ - даст хорошие результаты, ошибки будут минимальные.
Вопрос. Хорошо ли соотносится модульная структура с парадигмой ООП? Пакеты, модули, классы, методы (классов) подходят к "unix way"? Речь не идёт о множестве программ (уже готовых) и их объединении, речь идёт о разработке конкретной программы и подходе к разработке (деление на модули, слои, уровни, модели, контроллеры, etc.).
Комментариев нет:
Отправить комментарий