Познакомившись с сабжем я увидел следующие преимущества идеологии сигналов/слотов библиотеки QT:

Очевидное преимущество наблюдается в ситуации когда необходимо обрабатывать некоторое событие в классе А, но код этого класса недоступен для редактирования. В концепции классического ООП программирования (по крайней мере так было в Visual studio и в IDE от Borland пару лет назад, возможно что-то изменилось сегодня, пусть знатоки меня поправят) для разрешения данной ситуации создаются наследники класса А, а в их коде уже переопределяются нужные методы. Т.е. для обработки нажатия на кнопки мы создаем множество "оригинальных" классов. Это не очень хорошо по нескольким причинам:

1. Сказано "не плоди сущностей" и действительно не надо их плодить. Зачем зря перегружать код?

2. Хорошим тоном считается отделять бизнес-логику от внешнего вида. В случае классического подхода к событиям бизнес-логика вызывается в методе класса с которым это событие произошло. Т.е., например, вы можете внести код реализующий бизнес-логику непосредственно в метод нажатия кнопки А, а можете из этого метода вызвать другой метод Б, в котором уже будет реализована бизнес-логика. Оба этих варианта не очень красивы. Если вы поместили реализацию бизнес-логики непосредственно в метод нажатия кнопки, то это означает, что вы жестко привязали бизнес-логику к интерфейсу. Если же вы из А вызываете метод Б, то это награмождение кода - согласитесь, что метод просто вызывающий другой метод это не очень красиво.
В обоих случаях у вас появится затруднение, если в новой версии программы эти же действия будут вызываться не по нажатию кнопки, а скажем по щелчку на текстовом поле, или же и по тому и по другому. Казалось бы вам надо будет всего лишь перенести вызов метода Б в другие нужные методы. Да, это так, но вам придется редактировать код класса, который до того можно было назвать завершенным - готовым к использованию "черным ящиком". В случае достаточно большого проекта возвращаться к редактированию старых классов достаточно неприятно. При использовании сигналов и слотов также придется отредактировать вызов(ы) функции connect(), но вызов данной функции можно переместить в специально отдведенное для этого место (где вы связываете бизнес-логику с интерфейсом), что в классическом подходе невозможно.

3. Концепция сигналов и слотов повышает наглядность кода. Вы четче видите связь между событиями и реакцией на них. Наглядность подцепления одной реакции на множество событий выглядит куда нагляднее нежели в классическом подходе.

Хотелось бы узнать ваше мнение по данному предмету!