Naf,

5. А как без экзепшинов будет построена система управления ошибками (проверка входных, промежуточных, выходных данных)? Это ж геморойно без экзепшинов что-то мутить в проектах со сложной структурой и (тем более) при наличии нетривиального взаимодействия с пользователем (который априори источник ошибок в самых непредсказуемых местах).

1-4. Смотря что за задачи решает программа и что такое "достаточно сложная". Например фреймворк с кучей сложных алгоритмов по кодированию-декодированию (форматы изображений, текста, шифрование и т.д.) - можно. Там собственно все четко определено. А вот например реализуешь интерфейс сериализации/десериализации неважно чего. Собственно суть этого - набор объектов разных типов преобразовывать в один тип (строку или бинарник например). И наоборот - из этой строки восстанавливать реальные объекты конкретных типов. Любая крупная система управления разнотипными данными так или иначе сталкивается с необходимостью таких преобразований. Я даже не вижу никакого богохульства в том, чтобы когда мне надо проверить какого именно типа (из типов-реализаций) является конкретный объект.

Если же задача не требует наличия каких-то фабрик или менеджеров, в которых могут возникнуть подобные проверки, тогда хорошо - обойдемся. Но в общем случае - нет.

Абстрактная задача "Поменять масло" при реализации все же требует от тебя указать механику, какого бренда масло ты хочешь залить. Хотя теоритически можно было бы ужесточить условия задачи и пусть механик анализирует остатки масла в бачке - вот такое же пусть и заливает. Тогда твое указание на "тип" масла не потребуется. Но это же геморой, требует излишних телодвижений, оборудования, и заставляет тебя всю жизнь пользоваться одним и тем же маслом.

Вот как-то так.

Т.е. в ряде случаев обойтись без всех 4-х пунктов пропросту не удастся. В ряде - придется установить неудобные ограничения или вводить какие-то неюзер-френдли форматы данных. Ну а в остальных случаях - пожалуйста. И многие из этих случаев - "достаточно сложные программы" )))