Надеюсь, будет никак с этой темой:
http://rsdn.ru/forum/trash/6091539.1

Началось все с
Деструкторы — плохо, используйте явное освобождение ресурсов
Конструкторы — плохо, используйте фабрики, прячьте конструкторы в private
Множественное наследование — плохо
Наследование — всегда плохо, используйте агрегацию и интерфейсы
Интерфейсы со множеством вызовов — плохо, используйте интерфейсы с одним

* сюрприз, почти такие интерфейсы в Си с самого начала, при определении любой функции она приводится к указателю с типизированными параметрами прямо из коробки, только к этому "интерфейсу" еще this в качестве параметра надо добавить — вот уже почти современное ООП. Но инкапсуляция будет нарушена.

А инкапсуляция тоже не всегда хорошо. Когда тесты на какой то участок кода пишутся, нужно состояние окружения подменять на входе, а на выходе тестировать что оно изменилось в нужное. Т.е. и состояние тестируемого объекта и состояния объектов с которыми он взаимодействуют нужно устанавливать независимо от штатных методов объектов — жесткое нарушение инкапсуляции, и потом лезть во внутрь объекта за состоянием — тоже жестко нарушая инкапсуляцию. Состояние это вообщем-то все поля объекта.

Инкапсуляция — плохо для ТДД

* то что состояние this в Си-шных реализациях ООП легко отделимо от методов это то что надо для тестов


PS.
Итого, если код в более менее хорошей архитектуре, покрыт тестами, компилируется быстро и быстро работает — это по-прежнему код на СИ.
Когда ваш компилятор подвиснет в очередной раз на пару минут, задумайтесь над этим