for lang tid siden i landet Scala opstod ny type-sikker måde afhængighed injektion. På lang sigt bringer det flere problemer, end det er værd.

Kagemønster

lad os minde om, hvad der er et kagemønster. For at forstå det skal vi kende selvtyper. De var beregnet til at blive brugt som blandinger og ser mere eller mindre sådan ud:

trait UserRepository { def fetchUsers(userIds: Seq): Seq}class UserRepositoryDbImpl(database: Database) extends UserRepository { def fetchUsers(userIds: Seq): Seq = ...}trait UserRepositoryLogging { self: UserRepository => private lazy val logger: Logger = ... override def fetchUsers(userIds: Seq): Seq = { val users = super.fetchUsers(usersIds) logger.debug(s"""Fetched users by ids: ${users.mkString(", ")}""") users }}val userRepository: UserRepository = new UserRepositoryDbImpl(database) with UserRepositoryLogging

Her kan vi tilføje traitUserRepositoryLoggingtil noget, der erUserRepository implementering – det ville ikke kompilere ellers. Derudover inde UserRepositoryLogging vi antager, at det er implementeringen af UserRepository. Så alt tilgængeligt inden for UserRepository er også tilgængeligt der.

nu, da vi kan få adgang til, hvad der blev erklæret type(er), der blev brugt til selvtype, har vi lov til at gøre dette:

trait UserRepository { def fetchUsers(userIds: Seq): Seq}trait UserRepositoryComponent { def userRepository: UserRepository}trait UserRepositoryComponentImpl extends UserRepositoryComponent { lazy val userRepository: UserRepository = new UserRepository { // ... }}trait SomeController { self: UserRepositoryComponent => def handleRequest(userIds: Seq): Response = { // ... userRepository.fetchUsers(userIds) // ... }}object SomeController extends SomeController with UserRepositoryComponentImpl

inden forSomeControllerVi erklærer selvtype, der sikrer, at dens instantiable implementering vil haveuserRepository metode. Så ved at tilføje blandingen leverer vi implementeringen, og så sikrer vi, at afhængighed injiceres på kompileringstidspunktet. Uden runtime refleksion, med type-sikkerhed, ingen yderligere konfigurationer eller biblioteker.

hver sådan komponent kan være et lag af vores applikation (forretningslogiklag, infrastrukturlaget osv.), som nogen sammenlignede med lagene i kagen. Så ved at oprette din ansøgning på en sådan måde bager du effektivt en kage. Således kage mønster.

nu … hvorfor er det et problem?

tilføjelse af afhængigheder

i større projekter vil antallet af tjenester, arkiver og hjælpeprogrammer helt sikkert være større end 1-2. Så din kage vil begynde at se ud:

object PaymentTransactionApiController extends TransactionApiController with ConfigComponentImpl with DatabaseComponentImpl with UserRepositoryComponentImpl with SessionRepositoryComponentImpl with SecurityServicesComponentImpl with ExternalPaymentApiServicesComponentImpl with PaymentServicesComponentImpl with TransactionServicesComponentImpl

som et spørgsmål om, så jeg en gang en kage, hvorComponentImpl gik gennem 2-3 skærme. Du injicerede ikke kun komponenter-de-nødvendige-ad gangen, du kombinerede alt sammen på en gang: infrastruktur, domænetjenester, vedholdenhed, forretningslogik…

forestil dig nu, hvad der sker, når du skal tilføje en afhængighed. Du starter med at tilføje en anden with Dependency til din selvtype. Derefter kontrollerer du, hvor det opdaterede træk bruges. Du skal muligvis også tilføje selvtype her. Du klatrer op ad træet, indtil du når en klasse eller et objekt. Uff.

undtagen denne gang tilføjede Du dette selv, så du ved slags, hvad der skal tilføjes. Men når du laver rebase eller løser en konflikt, kan du ende i en situation, hvor der opstod en ny afhængighed, som du ikke har. Compiler fejl siger kun, at self-type X does not conform to Y. Med 50 + komponenter kan du lige så godt gætte, hvilken der fejler. (Eller begynde at gøre en binær søgning med at fjerne komponenter indtil fejl forsvinder).

Når kagestørrelse og mængden vokser yderligere, vil man måske implementere TØRREGEL og opdele den i mindre kager, der vil blive sat sammen senere. Dette afslører nye dybder af helvede.

fjernelse af afhængigheder

med normal DI når du holder op med at bruge et objekt, kan din IDE / compiler fortælle dig, at det ikke længere er nødvendigt, så du kan fjerne det. Med kage mønster, vil du ikke blive informeret om sådanne ting.

som et resultat er oprydning meget vanskeligere, og det er meget muligt, at du på et tidspunkt ender med meget mere afhængigheder, end du virkelig har brug for.

kompileringstid

alt dette tilføjer kompileringstiden. Det er måske ikke indlysende ved første øjekast, men du kan ende med:

trait ModuleAComponentImpl { self: ModuleBComponent => }trait ModuleBComponentImpl { self: ModuleAComponent => }

som er en cyklisk afhængighed. (Vi ved alle, at de er dårlige, men du bemærker måske ikke engang, at du lige har oprettet en. Især hvis du initialiserer alt dovent).

så disse 2 Træk vil blive meget ofte kompileret sammen, og det vil ikke hjælpe med det. Derudover vil ændringer til nogen af komponenterne i en kage udløse genkompilering af ting over det i afhængighedsgrafen.

test

cykliske afhængigheder skaber et andet problem. Du kan meget vel ende med noget som:

trait AComponentImpl { self: BComponent => lazy val a: A = new A { b.someMethod() // use b }}trait BComponentImpl { self: AComponent => lazy val b: B = new B { a.someMethod() // use a }}object Cake extends AComponentImpl with BComponentImplCake.a // NPE!Cake.b // NPE!

hver komponent vil være i sin egen fil, så du vil ikke bemærke denne afhængighed. Test med mock hjælper dig ikke med det:

trait BComponentMock { val b: B = mock }val aComponent = new AComponentImpl with BComponentMock {}aComponent.a // works!