Szczur napisał(a):
Na rynku istnieje kilka języków które się "przyjęły" i które się sprawdzają - C# / Java / C++ / Python i jeszcze kilka.
A zastosowania jak sami wiecie wielu języków się pokrywają i teraz dlaczego firma X ma użyć niezbyt popularnej w porównaniu do innych Scali? Jakie to da korzyści poza fajną składnią? Szybciej napiszę aplikację? Coś jak w pythonie? A później tak jak w pythonie koszta utrzymania / rozwijania gdy projekt się powiększy przerosną koszta utrzymania kodu w C++? Czy jak projekt się rozrośnie to wtedy Prezesowi firmy X powie się że musi przepisać aplikację?
Scala według mnie podzieli los języka D. Przynajmniej w perspektywie kilku najbliższych lat.
Z mojego doświadczenia to Scala w przeciwieństwie do Pythona dobrze się skaluje do dużych projektów, pod warunkiem podzielenia na mikroserwisy (barierą dla monolitów w Scali jest czas kompilacji). Scala jest statycznie typowana i ma bardzo rozbudowany system typów, przez co nawet więcej rzeczy niż w Javie może być sprawdzane na etapie kompilacji.
Zaletą Scali jest oczywiście szybkość pisania kodu, zwłaszcza kodu funkcyjnego. Java jest daleko w tyle, nawet mimo lambd w Javie 8.
Biały Młot napisał(a):
Wibowit napisał(a):
Ja spotkałem się z cake pattern, scala-guice i MacWire, ale możesz użyć chyba dowolnej biblioteki do DI. Chociaż niektóre pasują do Scali jak pięść do oka, np Spring.
A co jest najczesniej stosowane w Scali jesli w ogole? czy moze czesciej wszystko jest ładowane do traitsów?
Czy da sie w ogole wstrzykiwac do trait albo objects?
Trait to coś pomiędzy interfejsem i klasą, więc jeśli da się do tego wstrzykiwać to do traita też. Object w Scali to singleton i nie ma on parametrów konstruktora. Inicjalizacja objectu następuje w momencie pierwszego odwołania do niego, więc wstrzykiwania w objeccie się nie da zrobić - w sensie takiego jak np poprzez Guice. Za to objecty są konstruowane przy użyciu cake-pattern.
Nie wiem co jest najczęściej używane. Najlepiej porobić sobie kilka projektów z różnym podejściem i sprawdzić co bardziej podchodzi. Do małych projektów można w ogóle nie korzystać z żadnego wstrzykiwania tylko robić coś na zasadzie:
class Klasa(zależność1: Typ1, zależność2: Typ2) {
...
}
object Klasa extends Klasa(konkretnaZależność1, konkretnaZależność2)
Też działa, o ile w grafie zależności są same singletony. Dalej się łatwo testuje, bo w każdej klasie zależności są parametrami konstruktora, a nie odwołaniami na sztywno.
