Список проголосовавших за комментарий "<p>Replikant_mih, в целом, да.<br/> <br/> Честный ООП требует отдельного типа мышления, это бывает непросто даже для программистов. ООП незаменим для борьбы с колоссальной сложностью. Но процедурного или «почти процедурного» подхода вполне достаточно для того уровня сложности, с которым обычно приходится иметь дело.<br/> <br/> Если хочется более явно разграничить, можно использовать namespace'ы, если они есть в используемом языке. Классы в режиме namespace'ов тоже можно использовать, но это искусственно, уж лучше соответствующее именование, типа использования «префиксов» в именах.<br/> <br/> Тут, скорее, модель «иерархии библиотек» в качестве упрощённого ООП подойдёт лучше. Каждая «библиотека» предоставляет набор функций (сервисов), или API. «Библиотека», которая находится над ней, пользуется этим набором сервисов, чтобы предоставить уже свой набор функций более высокого уровня и так далее. «Библиотека» может использовать не одну, а несколько «библиотек» уровнем ниже. Получается такой упрощённый ООП, это значительно проще с точки зрения обычного мышления.<br/> <br/> Каждую «библиотеку» можно отладить отдельно, и это бывает удобно, поскольку каждая такая «библиотека», как правило, содержит набор логически связанных функций.<br/> <br/> Разбивку исходной задачи на условные «библиотеки» можно выполнить сверху вниз: сначала главную задачу разбить на подзадачи. Эти подзадачи будут решаться функциями «библиотеки» (или нескольких «библиотек», если подзадачи явно распадаются на несколько разнородных групп) верхнего уровня. Далее, каждую подзадачу, в свою очередь также разбить на подзадачи… пока подзадачи не станут достаточно простыми, чтобы решаться с помощью функции, решающей одну простую задачу. Примерно таков алгоритм построения иерархии (сверху вниз).<br/> <br/> Этот процесс многопроходный и итерационный, поскольку по мере разбивки начинают выясняться детали, которые были сразу не ясны на верхнем уровне, и которые требуют корректировки (а то и смены) дизайна программы. Но процесс полезный, поскольку разработчик, проходя его, начинает значительно лучше понимать, что и как будет происходить в разрабатываемой им программе.<br/> <br/> Во время процесса разбивки также следует постоянно помнить и учитывать возможность возникновения ошибочных ситуаций и дизайнить их обработку тоже. Обработка ошибочных ситуаций должна быть запрограммирована явно.<br/> <br/> Кстати, учёт ошибочных ситуаций может довольно сильно повлиять на дизайн всей программы…<br/> <span><br/> Разбивка получается сверху вниз, а реализация и отладка