Представьте, что перед вами стоит задача. Вы сначала попытаетесь воплотить её на самом простом и эффективном из доступных вам средств/языков (грубо говоря: написать на C, хотя и не обязательно, я сейчас не о конкретных языках а о принципе) и только если станет ясно, что запутываетесь и реально нужны более сложные средства (скажем очевидно, что ООП сильно помогло бы или вообще без сборки мусора явно плохо), примените их или наоборот сначала быстро решите её пусть даже с большим оверхедом на самом навороченном из доступных средств? Для чистоты эксперимента предположим что у вас идеальные условия -- время не давит, начальство всем довольно, заказчики с кровавыми топорами к двери кабинета не подкрадываются. Лично я встречал людей, которые эффективно пишут хороший код и по первому и по второму принципам. И я видел откровенно никчёмный код написанный и так и так.
Но в защиту первого принципа у меня есть очень как мне кажется веский аргумент и имя ему -- повторное использование. Модуль написанный на чистом C вы сможете использовать на любом проекте. Модуль написанный на C++ с исключениями и STL вы сможете использовать повторно только если у вас на проекте есть STL и разрешены исключения. Модуль, написанный на C++/CLI вы сможете использовать только если в проекте разрешен .Net (хотя бы в виде CLR-хостинга) и т.д. То есть чем более мощные и удобные средства вы использовали при написании кода, тем ниже шансы его повторно использовать.
Ещё хуже -- *иллюзия* возможности реюза, которую дают классы. Вы наследуетесь от кого-то, первый месяц всё идёт хорошо, а потом вы упираетесь в нечто неожиданное внутри этого класса и приходится писать убогие подставки и костыли. Лично я уже очень давно и основательно боюсь излишнего наследования -- простое использование хорошо написанного чужого класса кажется более безопасным и то только если покрыть юнит-тестами вдоль и поперёк.
Отдельная песня -- повторное использование на бинарном уровне. Unmanaged-DLL в которой наружу выставляются функции C-интерфейса (а лучше если ещё и stdcall) может быть использована в пределах Win32 кем угодно и мне даже из managed-кода не возникало никогда проблем такие задействовать. Сложнее если наружу торчат классы. Ещё сложнее если это внутрипроцессный COM-сервер. Я скромно молчу про Java и .Net в этом отношении -- там наличие чего-то, что вы хотите повтрно использовать написанного на данном фреймворке *и уже собранного* по сути привязывает вас к фреймворку.
Ещё более интересный вопрос -- самодисциплина. Но это уже индивидуально и холиворно.
Вот интересно, это мне просто сильно не везло в жизни с тем, что я пытался реюзать или это у всех после некоторого опыта наступает такой период?
P.S. Я не говорю здесь об оптимизации. Решение простыми средствами может быть и не очень оптимальным, если это предполагает скажем самописный malloc и memcpy (да, бывает и такое если CRT запрещён). Оптимизация ясное дело всегда на потом. Исключительно о простоте используемых средств.
P.P.S. Ссылки на статьи и литературу философски-практического плана очень приветствуются. Буча, Страуструпа, Александреску, Фаулера и GoF читал.
