Конструктор по умолчанию по сравнению с контейнером IOC
Чтобы загрузить значения из Qt Stylesheet, вы должны вызвать следующие методы:
widget->style()->unpolish(widget);
widget->style()->polish(widget);
widget->update();
После этого все значения вашего виджета будут обновляться в соответствии с указанными вами значениями стилей.
8 ответов
Идея МОК состоит в том, чтобы делегировать часть функциональности Вашего компонента к другой части системы. В мире МОК у Вас есть компоненты, которые не знают друг о друге. Ваш пример нарушает это, поскольку Вы создаете плотное соединение между MyClass и некоторой реализацией IMyInterface. Основная идея состоит в том, что Ваш компонент не знает о том, как он будет использоваться. В Вашем примере Ваш компонент делает некоторые предположения о своем использовании.
На самом деле этот подход может работать, но смешивание МОК и явной объектной инициализации не является хорошей практикой IMO.
МОК дает Вам слабую связь путем выполнения позднего связывания за цену ясности кода. Когда Вы добавляете дополнительное поведение к этому процессу, оно делает вещи еще более сложными и может привести к ошибкам, когда некоторые компоненты могут потенциально получить объект с нежелательным или непредсказанным поведением.
Выберите сторону :)
В коротком МОК рекомендуется. Проблема с кодом состоит в том, что я не могу выгрузить реализацию по умолчанию зависимости, не перекомпилировав код, как Вы заявили в конце. МОК позволяет Вам изменять конфигурацию или состав Вашего объекта во внешнем файле без перекомпиляции.
МОК принимает "конструкцию и блок" ответственность от остальной части кода. Цель МОК не состоит в том, чтобы сделать Ваш код тестируемым... это - приятный побочный эффект. (Точно так же, как код TDDed ведет для лучше разработки),
Помимо слабой связи, МОК уменьшит дублирование кода. Когда Вы используете МОК, и Вы хотите изменить реализацию по умолчанию своего интерфейса, необходимо изменить его только в одном месте. При использовании конструкторов по умолчанию для введения реализации по умолчанию, необходимо изменить ее везде, интерфейс используется.
Нет ничего неправильно с этим кодом, и можно все еще использовать его с платформами Внедрения зависимости как Spring и Guice.
Многие разработчики рассматривают конфигурационный XML-файл Spring как преимущество перед проводным соединением зависимостей в рамках кода, поскольку можно переключить реализации, не нуждаясь в шаге компиляции. Это преимущество на самом деле осознано в ситуациях, где у Вас уже есть несколько реализаций, скомпилированных в Вашем пути к классу, и Вы хотите выбрать реализацию во время развертывания. Можно вообразить ситуацию, где компонент обеспечивается третьим лицом после развертывания. Так же может быть случай, когда Вы хотите поставить дополнительные реализации как патч после развертывания.
Но не все платформы DI используют конфигурацию XML. Google Guice, например, записали Модули как классы Java, которые должны быть скомпилированы как любой другой класс Java.
Таким образом, каково преимущество DI, если Вам даже нужен шаг компиляции? Это забирает нас к Вашему исходному вопросу. Я вижу следующие преимущества:
- Стандартный подход к DI всюду по приложению.
- Конфигурация аккуратно разделяется из другой логики.
- Способность ввести прокси. Spring, например, позволяет Вам делать декларативную обработку Транзакции путем введения прокси вместо реализации
- Более легкое повторное использование логики конфигурации. При использовании DI экстенсивно Вы будете видеть сложное дерево зависимостей, развивающихся со временем. Управление им без ясно выделило слой конфигурации, и поддержка платформы может быть кошмаром. Платформы DI помогают снова использовать логику конфигурации посредством наследования и других средств.
В дополнение к другим комментариям можно было спорить, DRY (Не Повторяйте Себя), принцип в этих случаях. Это избыточно для помещения того кода конструкции по умолчанию в каждый класс. Это также представляет обработку особого случая, где не должно быть никого.
Я не вижу, почему Ваш метод жесткого кодирования реализация по умолчанию не мог использоваться вместе с контейнером МОК. Просто, зависимости, которые Вы не указываете в конфигурации, взяли бы реализацию по умолчанию.
Или я пропускаю что-то?
Одна причина Вы могли бы хотеть использовать Контейнер МОК, будет состоять в том, чтобы упростить последнюю конфигурацию Вашего программного обеспечения.
Скажите, например, Вы обеспечиваете несколько реализаций конкретного интерфейса - клиент (или Ваша профессиональная сервисная команда) может решить который использовать путем изменения конфигурационного файла МОК.
Единственное, что меня беспокоит: (1) если ваша зависимость службы по умолчанию имеет другую / вторичную зависимость службы (и так далее ... ваш DefaultMyInterface зависит от ILogger) и (2) вам необходимо изолировать первую зависимость службы от второй (нужно протестировать DefaultMyInterface с помощью заглушки ILogger). В этом случае вам, очевидно, нужно будет потерять "новый DefaultMyInterface" по умолчанию и вместо этого выполнить одно из: (1) внедрение чистой зависимости или (2) локатор службы, или (3) container.BuildUp (new DefaultMyInterface ());
Некоторые из перечисленных выше плакатов могут быть несправедливыми по отношению к вашему вопросу. Вы не спрашивали о нескольких «производственных» реализациях. Вы спрашиваете о модульном тестировании . В случае тестирования подразделения ваш подход, с моей первой оговоркой, кажется законным; Я бы тоже подумал об использовании его в простых модульных тестах.
Точно так же пара респондентов выразила озабоченность по поводу репитативности. Мне тоже не нравится повторение, но если (1) ваша реализация по умолчанию действительно является вашей по умолчанию (YAGNI: у вас нет планов по изменению значения по умолчанию) и (2) вы не верите, что первое предостережение, которое я сформулировал, применимо и (3) предпочитайте более простой подход к коду, которым вы поделились, тогда я не думаю, что эта конкретная форма повторения является проблемой.