Alternative Strategy for Dependency Injection (lambda-returning vs function-pointer)

There's some common strategy for injecting dependency (one or sets of function) using interface, something like this:

type Foo interface{ Bla() string }
type RealAyaya struct {}
func(a *RealAyaya) Bla() {}

type MockAyaya struct {} // generated from gomock or others

func(a *MockAyaya) Bla() {}
// real usage:

deps := RealAyaya{}

deps.Bla()

// test usage:

deps := MockAyaya{}

deps.Bla()

and there's another one (dependency parameter on function returning a lambda):

type Bla func() string

type DepsIface interface { ... }
func NewBla(deps DepsIface) Bla {
  return func() string {
    // do something with deps
  }
} 

// real usage:

bla := NewBla(realDeps)

res := bla()

// test usage:

bla := NewBLa(mockedOrFakeDeps)

res := bla()

and there other way by combining both fake and real implementation like this, or alternatively using proxy/cache+codegen if it's for 3rd party dependency.

and there other way (plugggable per-function level):

type Bla func() string
type BlaCaller struct {

  BlaFunc Bla
}
// real usage:

bla := BlaCaller{ BlaFunc: deps.SomeMethod }
res := bla.BlaFunc()

// test usage:

bla := BlaCaller{ BlaFunc: func() string { return `fake` } }
res := bla.BlaFunc()

Analysis

The first one is the most popular way, the 2nd one is one that I saw recently (that also being used in openApi/swagger codegen, i forgot which library), the bad part is that we have to sanitize the trace manually because it would show something like NewBla.func1 in the traces, and we have to use generated mock or implement everything if we have to test. Last style is what I thought when writing some task, where the specs still unclear whether I should:
1. query from local database

2. hit another service

3. or just a fake data (in the tests)

I can easily switch out any function without have to depend on whole struct or interface, and it would be still easy to debug (set breakpoint) and jump around the method, compared to generated mock or interface version.

Probably the bad part is, we have to inject every function one by one for each function that we want to call (which nearly equal effort as the 2nd one). But if that's the case, when your function requires 10+ other function to inject, maybe it's time to refactor?

The real use case would be something like this:

type LoanExpirationFunc func(userId string) time.Time 

type InProcess1 struct {
  UserId string // add more input here

  LoanExpirationFunc LoanExpirationFunc

  // add more injectable-function, eg. 3rd party hit or db read/save
}

type OutProcess1 struct {}
func Process1(in *InProcess1) (out *OutProcess1) {

  if ... // eg. validation

  x := in.LoanExpirationFunc(in.UserId) 
  // ... // do something
}

func defaultLoanExpirationFunc(userId string) time.Time {
  // eg. query from database

}

type thirdParty struct {} // to put dependencies
func NewThirdParty() (*thirdParty) { return &thirdParty{} }
func (t *thirdParty) extLoanExpirationFunc(userId string) time.Time {

  // eg. hit another service
}

// init input:

func main() {
  http.HandleFunc("/case1", func(w, r ...) {
    in := InProcess1{LoanExpirationFunc: defaultLoanExpirationFunc}
    in.ParseFromRequest(r)

    out := Process1(in)  

    out.WriteToResponse(w)
  })
  tp := NewThirdParty()

  http.HandleFunc("/case2", func(w, r ...) {
    in := InProcess1{LoanExpirationFunc: tp.extLoanExpirationFunc}
    in.ParseFromRequest(r)

    out := Process1(in)  

    out.WriteToResponse(w)
  })

}

// on test:

func TestProcess1(t *testing.T) {

  t.Run(`test one year from now`, func(t *testing.T) {
    in := inProcess1{LoanExpirationFunc: func(string) { return time.Now().Add(1, 0, 0) }}

    out := Process1(in)

    assert.Equal(t, out, ...)
  })

}

Haven't using this strategy extensively on new a project (since I just thought about this today and yesterday when creating horrid integration test), but I'll update this post when I found annoyance with this strategy.

 

UPDATE 2022: after using this strategy extensively for a while, this one is better than interface (especially when using IntelliJ), my tip: it would be better if you use function pointer name and injected function name with same name.