«Встроенное внедрение зависимостей» в scala

1

Привет, следующий пост говорит, что "встроенная инъекция зависимостей" в scala

"Как разработчик Scala и Java, я даже не испытываю соблазна заменить Scala своим основным языком для моего следующего проекта с Java 8. Если я вынужден писать Java, это может быть лучше Java 8, но если у меня есть выбор, есть так много вещей (как правильно утверждается OP), которые заставляют Scala заставлять меня за пределами Lambdas, что просто добавление этой функции в Java на самом деле для меня ничего не значит. Ruby имеет Lambdas, так что Python и JavaScript, Dart и Я уверен, что любой другой современный язык. Мне нравится Scala из-за многих других вещей, кроме лямбда, что одного комментария недостаточно.

Но назвать несколько (некоторые ссылались на ОП)

Все это выражение, для понятий (особенно с несколькими фьючерсами, разрешение треугольника обратного вызова смерти в красивом синтаксисе IMHO), неявные преобразования, классы Case, сопоставление образцов, кортежи, факт, что все имеет равные и хэш-коды, которые были правильно реализованы (так Я могу поместить кортеж или даже массив в качестве ключа на карте), строчную интерполяцию, многострочную строку, параметры по умолчанию, именованные параметры, встроенную инъекцию зависимостей, самую сложную и самую мощную систему типов на любом языке, который я знаю, типа (не так хорошо, как Haskell, но лучше, чем не существующий в Java). Тот факт, что я всегда получаю правильный тип, возвращался из набора "монадических" действий благодаря печально известным вещам, таким как CanBuildFrom (которые являются чистым гением). Пусть не забывают пропуски по аргументам имен и возможность построения DSL. Экстракторы (с помощью сопоставления с образцом). И еще много.

Я думаю, что Scala здесь, чтобы остаться, по крайней мере для разработчиков Scala, я на 100% уверен, что вы не найдете ни одного разработчика Scala, который скажет: "Java 8 получил lambdas? Отлично, до свидания scala навсегда!". Единственная причина, по которой я могу думать, - это время компиляции и двоичная совместимость. Если мы проигнорируем эти два вопроса, все, что я могу сказать, так это то, что это просто доказывает, что Scala находится в правильном направлении (так как на Java 8 lambdas и методы интерфейса и пары по умолчанию так сильно влияют)

Однако я хочу, чтобы Scala улучшила совместимость с Java 8, например, поддерживала функциональные интерфейсы одинаково. и добавить новые неявные преобразования в коллекции Java 8, а также воспользоваться преимуществами JVM.

Я заменю Scala, как только найду язык, который дает мне то, что делает Scala, и делает это лучше. До сих пор я не нашел такого языка (рассмотрел Haskell, Clojure, Go, Kotlin, Ceylon, Dart, TypeScript, Rust, Julia, D и Nimrod, Ruby Python, JavaScript и С#, некоторые из них были очень перспективными, но поскольку я нужен язык JVM и, желательно, статически типизированный, он довольно быстро сузил выбор)

Java 8, безусловно, даже не закрывается, извините. Большое улучшение, я очень доволен разработчиками Java, которые получат "разрешение" на его использование (может быть, легче принять, чем Scala на предприятии), но это не является поводом для того, чтобы магазин Scala решил вернуться к Java ". [ 1 ]

что такое built in dependency injection в scala?

Теги:
dependency-injection

1 ответ

7
Лучший ответ

Это не дискретная языковая функция. Я думаю, что автор имел в виду тот факт, что набор функций Scala достаточно гибкий, чтобы поддерживать ряд методов, которые можно было бы сказать для выполнения DI:

Это разнообразие довольно символично для Scala. Язык был разработан для реализации ряда очень мощных концепций, в основном ортогональных, что привело к множеству действительных способов решения многих проблем. Задача программиста Scala - понять эту широту, а затем сделать разумный выбор для вашего проекта. Много раз этот выбор зависит от того, какие парадигмы используются внутренне для реализации ваших компонентов.

Поделиться
  • 0
    Я думаю, что четвертый подход, использующий неявные параметры класса, очень похож на выражение «передать зависимости как аргументы класса». Это лишь немного уменьшает раздувание кода и открывает гибкость в отношении того, откуда возникнет зависимость (неявная вызывающая сторона, импорт и т. Д.).
  • 1
    На самом деле, я думаю, что они имеют тенденцию не сильно влиять на раздувание кода при использовании для зависимостей, поскольку единственное место, которое им не нужно упоминать, - это сайт вызова, но вам нужно помечать implicit везде, чтобы передавать их по нашему потреблять их. Я на самом деле использую их для передачи библиотечных зависимостей, в стиле Akka с неявной системой акторов и т. Д. Но затем я делаю свои API-функции явными. Это, кажется, обеспечивает хорошее различие между инфраструктурой и зависимостями данных.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню