Наблюдатели по сравнению с обратными вызовами
"Строгий контроль типов" и его противоположный "слабый контроль типов" довольно слабы в значении, частично начиная с понятия того, что считается "сильным", может варьироваться в зависимости от того, кого Вы спрашиваете. Например, C был назван и "со строгим контролем типов" и "со слабым контролем типов" различными авторами, он действительно зависит от того, с чем Вы сравниваете его.
Обычно систему типов нужно считать более сильной, если она может выразить те же ограничения как другой и т.д. Довольно часто две системы типов не быть сопоставимыми, хотя - можно было бы иметь функции другой, недостает и наоборот. Любое обсуждение относительных преимуществ тогда до персонального вкуса.
Наличие более сильной системы типов означает, что или компилятор или время выполнения сообщат о большем количестве ошибок, который обычно является хорошей вещью, хотя это могло бы прибыть за счет необходимости предоставить больше информации о типе вручную, которую можно было бы считать усилием, не стоящим. Я утверждал бы, что "строгий контроль типов" обычно лучше, но необходимо посмотреть на стоимость.
также важно понять, что "со строгим контролем типов" часто неправильно используется вместо или даже "введенной декларации "со статическим контролем типов"". "Со статическим контролем типов" означает, что существуют проверки типа во время компиляции, "декларация, введенная", означает, что типы объявляются явно. Ввод декларации является, вероятно, самым известным способом сделать систему типов более сильной (думайте Java), но можно добавить силу другими средствами, такими как вывод типа.
2 ответа
Обратный вызов является более коротким: вы передаете его в функцию, которая будет вызываться один раз. Это часть API в том смысле, что вы обычно не можете вызвать функцию, не передав обратный вызов. Эта концепция тесно связана с тем, что делает функция. Обычно вы можете передать только один обратный вызов ..
Пример: Запуск потока и выполнение обратного вызова, который вызывается, когда поток завершается.
Наблюдатель живет дольше, и его можно присоединить / отсоединить в любое время. Для одного и того же объекта может быть много наблюдателей, и у них может быть разное время жизни.
Пример: отображение значений из модели в пользовательском интерфейсе и обновление модели на основе пользовательского ввода.
Вы можете использовать наблюдателей как средства разделения или распределения ответственности. В основном смысле - если код вашей модели становится слишком беспорядочным, подумайте об использовании наблюдателей для какого-то несущественного поведения. Настоящая сила (по крайней мере, как я это вижу) наблюдателей заключается в их способности служить точкой соединения между вашими моделями и некоторой другой подсистемой, функциональность которой используется всеми (или некоторыми) другими классами. Допустим, вы решили добавить в свое приложение IM-уведомление - допустим, вы хотите получать уведомления о некоторых (или всех) действиях CRUD некоторых (или всех) моделей в вашей системе. В этом случае использование наблюдателей было бы идеальным - ваша подсистема уведомлений будет полностью отделена от вашей бизнес-логики, а ваши модели не будут загромождены поведением, которое не относится к их сфере деятельности. Еще один хороший вариант использования для наблюдателей - это подсистема аудита.