Когда использовать сигналы и слоты и если не к

Mono 2,6 поставляется с DbLinq . Это не удобно, хотя и вы должны пройти через некоторую боль, прежде чем вы можете сделать это работать.

Проверьте это на MSDN Как написать простой проект MSBuild .

Ее хорошая статья и помогла мне начать.

Вот pdf печатной версии того же.

Сигналы/слоты (также называемые событиями) являются хорошим способом удаления связи между объектами.

Например, вместо того, чтобы иметь представления, которые понимают, как работает модель, и когда модель изменяется, они «слушают» модель. Модель отвечает за то, чтобы говорить, когда она меняется, что меняется.

Проблема с событиями заключается в том, что вы разрабатываете события с учетом требований клиента. Например, не следует иметь сигнал displayInfoScreen , поскольку он предполагает что-то об объектах, использующих этот сигнал. Вместо этого он должен иметь значение infoChanged , и InfoScreenDisplayer прослушивает эти сигналы для их отображения на экране. При необходимости позднее можно добавить InfoTweterPoster , который размещает информацию в Твиттере при каждом изменении.

Можно ли использовать сигналы для сообщения об ошибках?

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

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

Можно ли предполагать, что сигнал будет обработан?

Сигналы (с философской точки зрения) предназначены для обозначения того, что что-то произошло. Как указывали другие, никогда не стоит предполагать, что сигнал будет согласован со слотом или даже только с одним другим слотом.

Могут ли сигналы использоваться для инициирования действий? Например. signal displayInfoScreen () должен обрабатываться слотом, который показывает информационный экран.

Сигналы можно использовать для инициирования действий, но, вероятно, не так, как вы думаете.Сигнал указывает, что произошло foo . Если код, отслеживающий ваш класс, решает, что когда происходит foo , должно отображаться диалоговое окно, значит, сигнал был использован для инициирования этого действия. Однако обычно класс, излучающий сигнал, не несет ответственности за выполнение правильного действия, потому что он не несет ответственности за выполнение этого действия. (Если бы это было так, то он должен быть частью того же класса, и никакой сигнал не потребуется.)

Сигналы и слоты являются мощными, потому что развязывают объекты. Вы не можете предположить, что к сигналу подключен слот, как было отвечено ранее.

Основной недостаток проектирования на основе сигналов/слотов заключается в том, что вы можете очень легко потерять контроль над реализованной логикой, поскольку одно действие объекта может вызвать другие действия любого другого объекта, подключенного к испускаемому сигналу. Гораздо проще получить нежелательные побочные эффекты, рекурсивные вызовы и т.д.

Можно ли предположить, что сигнал будет обработан?

Нет, это не так. Сигналы - это вещи типа "пустил и забыл". Кто подключается к сигналу и что он делает, эмитента не должно волновать.