Каковы за и против для использования контейнера МОК?
Вот ваш цикл, написанный с vapply
out <- vapply(1:nrow(cars),
function (i) {
valA <- .subset2(cars, 1)[i] + 45L
valB <- .subset2(cars, 1)[i] + 10L
c(valA, valB)
}, numeric(2))
t(out)
# [,1] [,2]
# [1,] 49 14
# [2,] 49 14
# [3,] 52 17
# [4,] 52 17
# [5,] 53 18
# [6,] 54 19
# [7,] 55 20
# ...
# (returns an array instead of a list, but that can be changed easily).
Кстати, я не знаю, какова ваша конечная цель, но в этом примере, почему любой цикл вообще?
# vectorized
cbind(.subset2(cars, 1) + 45L, .subset2(cars, 1) + 10L)
# [,1] [,2]
# [1,] 49 14
# [2,] 49 14
# [3,] 52 17
# [4,] 52 17
# [5,] 53 18
# [6,] 54 19
# [7,] 55 20
# ...
# or similar result with
# getDetails(cars) (version with c())
7 ответов
При использовании контейнера МОК простым способом отражение только используется на запуске - приложение обеспечено электричеством для начала, и затем это работает как нормальное без любого вмешательства от контейнера. Конечно, если Вы используете МОК для разрешения зависимостей после того, как Вы начали работать, который может немного отличаться - хотя я все еще ожидал бы, что это будет решать лениво и кэшироваться, если Вам не настроили его для создания новых экземпляров каждый раз.
Что касается создания кода тяжелее для понимания - нечто противоположное! С зависимостями, явно указанными, намного легче понять каждый компонент, и конфигурационный файл (файлы) проясняет, как целое приложение остается целым.
Я соглашаюсь со всеми ответами до сих пор.
То, что я хотел бы добавить, то, что это создает немного служебное, таким образом, это действительно не подходит для небольших приложений.
И объемные приложения среднего размера извлекают выгоду больше всего из использования МОК.
Вы могли бы также проверить этот вопрос для получения дополнительной информации о за и против: замок Windsor Are There Какие-либо Оборотные стороны?
Хорошо я предполагаю довод "против", который я испытал, то, что некоторые разработчики, кажется, не могут схватить МОК. У нас было несколько человек, которые были против него ни по какой причине, кроме которой они не поняли их. (Не высказывание это - плохая причина быть против чего-то, нисколько.)
Это действительно добавляет немного абстракции, которой всегда, кажется, удается смутить того или иного, но я сказал бы, что профессионалы явно перевешивают недостатки в большинстве случаев.
Я думаю, что справедливости ради стоит отметить, если у Вас будет опытное понимание того, как использовать МОК и склонными писать хороший код так или иначе, затем МОК сделает Ваш код легче понять на всех кроме самых маленьких систем.
Однако, если Вы работаете где-нибудь, где большинство классов/методов является очень большим, и понятие рефакторинга еще не утвердилось, затем пытаться использовать МОК вероятно только сделать программное обеспечение тяжелее для понимания. МОК также должен быть наклонен всеми, что программы на проекте, так, чтобы могло быть соображение.
Я рассматриваю МОК как обледенение на пироге; мне нравится обледенение, но только на хорошем пироге. Если пирог не хорош для начала, разберитесь в пироге сначала.
Относительно производительности наверху использования МОК, я не рассматриваю это как проблему в большинстве случаев. Служебное не должно быть большим, и, учитывая скорость сегодняшнего ЦП большинство из Вас, время выполнения, вероятно, будет доступом к данным так или иначе. Если бы МОК, оказалось, замедлился для данного бита кода, то я посмотрел бы на добавление некоторого кэширования возвращенного объекта или удаления МОК только от того бита кода.
Я полагаю, что предположение об уменьшенной скорости выполнения является почти таким же видом аргумента, поскольку "C быстрее, чем C#/Java". В то время как этот оператор может быть верным для определенных операций и/или структурно простых задач, он не имеет место повышения сложности момента.
Путем платформы DI позволяют, Вы сфокусироваться на создании объекта и зависимостях создаете более эффективные системы, когда размер кода увеличивается. Для крупных приложений я - почти определенный основанный на платформе DI код, превзойдет любое альтернативное решение по характеристикам. Существует просто так мало дублирования во времени выполнения, что трудно сделать это более эффективным! Большинство дополнительных издержек также только при первой загрузке.
Усовершенствованные контейнеры DI также позволяют, Вы действительно "определяете объем" волшебства, что можно только мечтать о без контейнера. Используя прокси объема, пружина может сделать следующее:
A Singleton
|
B Singleton
|
C Prototype (per-invocation)
|
D Singleton
|
E Session scope (web app)
|
F Singleton
Эффективно у Вас может быть десять слоев одноэлементных объектов и внезапно чего-то, что ограниченная по объему сессия разоблачает.
Материал как безопасность может быть введен полностью другим способом, чем Вы были бы иначе. Часто существует классический парадокс: Часто уровень GUI должен иметь сложное знание прав доступа. Довольно часто для сервисного слоя также нужно это, но часто в другом уровне детализации (обычно менее подробный, чем gui). Классический подход должен был бы отправить его вокруг как параметры, выразиться на threadlocal или спросить сервис. С пружиной можно просто ввести его straght, где Вам нужен он, и никто еще не должен знать.
Это на самом деле изменяет разработку приложений в целом. У меня было очень твердое время, корректируясь к этому, но после этой боли я вижу, что это действительно намного ближе к тому, как вещи должны быть (в противоположность тому, как мы учились делать это).
Таким образом, я думаю, что платформы DI имеют потенциал изменения путем, Вы делаете программы с гораздо дальше достигающими последствиями, чем просто DI. Это не просто прославленный способ назвать новым.
При большинстве обстоятельств Вы даже не заметили бы потерю производительности, так как для "одиночного элемента" возражает, что вся инициализация выполняется однажды только. Я также утверждал бы, что МОК делает это отличающимся для понимания кода: наоборот, разработка стиля МОК вынуждает Вас создать маленькие когерентные классы, которые в свою очередь легче к grok.
Если Вы пишете, что бизнес-приложение, с помощью контейнера инверсии управления и внедрения зависимости (в сочетании с другими гибкими методами и инструментами) выручит Вас с точки зрения производительности и надежности.
Кроме того, Ваше приложение, вероятно, потратит подавляющее большинство своего процессорного времени, ожидая ресурсов или ожидая человеческого взаимодействия и не делая ничего полезного. Ваше приложение должно иметь много лошадиной силы для экономии в течение нескольких микросекунд отражения.