Статических классов нужно избежать, потому что это делает Внедрение зависимости Трудным?
проверить перечисление внутри уведомления словарь userInfo
NSNumber *reason = [notification.userInfo objectForKey:MPMoviePlayerPlaybackDidFinishReasonUserInfoKey];
if ([reason intValue] == MPMovieFinishReasonUserExited) {
// done button clicked!
}
Выбранный ответ с тех пор интегрировал мой ответ. Пожалуйста, обратитесь выше.
2 ответа
Статические классы (методы) не обязательно следует избегать, если они не имеют скрытых зависимостей. Конечно, вы можете передавать зависимости в статический метод - он просто не должен храниться внутри и изменять поведение последующих вызовов.
Не должно возникнуть проблем с их проверкой и в этом случае.
Но у меня тоже плохое предчувствие по поводу упомянутых вами случаев. Я знаю некоторые из этих статических служебных классов-оберток - и в большинстве случаев они действительно воняют :)
РЕДАКТИРОВАТЬ:
Может быть, мне следует уточнить. Я бы использовал статические классы / методы только для очень небольших важных задач. Когда статические классы начинают инициализировать зависимости, их, безусловно, следует избегать. Если вы не можете протестировать эти статические классы, у них уже есть слишком большая работа.
В первом ответе на этот вопрос приведены аргументы против статических классов, как вы упомянули.
Насколько сложно было бы изменить эти статические классы для использования внедрения зависимостей? Если вы сделаете DI необязательным (если возможно), вы можете создать ситуацию, в которой вы можете использовать статические классы для имитации, просто правильно выполнив DI, не изменяя при этом ни одно из «нормального» поведения.