[vasketsov]

хотя и использующие процедурный метод тоже можно - мож кому интересно

Сразу же по поводу возможного благоговения перед объектами. Кроме религиозных споров на тему дизайна и у кого что длиннее, есть один факт, из-за которого процедуры никогда не заменятся объектами, это работа на низком уровне, в разных системах этот уровень абстракции различный, но в итоге сетевая плата про ваши объекты ничего не знает и знать не хочет. Поэтому здоровый пессимизм по отношению к OOA/OOD/OOP всегда должен иметь место.

Про объекты - почитай Буча и про паттерны, хотя второе опционально и небесспорно, копий на эту тему сломано ой как немало. Про проектирование гуя - рекомендую почитать мелкосаксные документы, а также настоятельно советую - рекомендации "Designed for ..." для различных систем. Совершенно необходимо знать принципы проектирования БД (реляционных - как минимум, объектных - от ветрености конторы, серьезные организации еще не могут себе позволить хранить данные в объектных базах, на это есть определенные причины).

Рихтера "Программирование серверных пролижений" не рекомендую, непосредственно по проектированию книжка никакая.

Второй момент. При проектировании приложения существенную роль играет то окружение, в котором оно будет выполняться, и все сентенции по поводу stdio и прочих кроссплатформенных ансишных или плюсовых вкусностей в реальных больших и прежде всего распределенных приложениях упираются в специфику платформ, прежде чем мысль о минимальной оптимизации придет в голову, в случае же оптимизации кода привязка к платформе - просто факт. Правильное проектирование начинается с анализа требований, потому выбор систем разработки и даже операционных систем (даже отдельных версий!) должен являться вторичным. Исходя из этого, основное требование к человеку, разрабатывающему архитектуру системы - общая глубокая эрудиция, все книжки ничего кроме мнения автора не отражают. Один пишет, что за перегрузку оператора [] надо расстреливать, другой этой перегрузкой ловко пользуется, оба широко известны - а прав в итоге тот, кто правильно это использует. Третий пишет о недопустимости передачи стековых объектов по ссылке, четвертый - что не стоит вызывать функции API если это можно сделать через использование только стандартных плюсовых функций, пятый ненавидит конструкторы по умолчанию и все что с ними связано, большинство слыша словосочетание "виртуальный конструктор" крутит пальцем у виска, хотя можно создать реальный виртуальный конструктор и им замечательно пользоваться - короче, варианта 2 либо думаем сами (на самом деле это не трудно), либо читаем N книжек и потом логическим умножением выделяем из них истину, лучше и то и другое одновременно.

[TEHb]

Ни о каком благоговении перед объектами речь не идет!!! Всё дело в том, что я в какой-то степени знаком с CASE-средствами (основной процесс, основные потоки; далее детализация, поток сюда, поток туда...), но все они опираются на процедурное програмирование (опять же повторюсь, что против него не имею ничего против), но иногда и на объектах хотца пописать.
Дальше. Эрудиция эрудицией, но она появляется с опытом, а опыт приходит вместе с практикой, а чтобы практиковаться - нужна теория, а велосипед изобретать неохота, поэтому книжки и читаю и думаю, что все остальные также поступают  
А про мнение автора - так ты сам все и сказал в конце - прочитал, выделил для себя истину и вперед! Стандартные ступени получения навыков: знакомство с теорией -> копирование мастера (ну, если хотите, учителя) -> выработка собственного стиля (и, естественно, своих взглядов на [] и иже с ними)
ЗЫ: и все же хотелось бы, если возможно, про конкретные книги услышать побольше. Наверное, есть же какие-ньть классические труды.