di

[christophberger]

Written on 02/25/2017 15:43:33

URL: https://appliedgo.net/di/

[christophberger]

Migrated comment, written by Prathamesh Juvatkar on 10/27/2017 03:37:05

This works well in case of Poem entity not depending on other entities. However when there are multiple entities depending on each other, those might not be stored the same way, for example in case of nosql implementation, storage of one entity will depend on other entities. In that case, it makes sense to create DAO interface for accessing entity and accessor implementation may use multiple entities.

[christophberger]

Migrated comment, written by Christoph on 10/30/2017 09:13:11

The article intentionally discusses a very simple scenario only, in order to demonstrate the basics of dependency injection and to avoid that the message is lost between too much code noise. You rightly point out that real-world cases are generally more complex than this one. However, the principles of dependency injection still work the same way even in complex cases - see, for example, the article "Applying The Clean Architecture to Go applications" (link available in the Further Readings section).

[christophberger]

Migrated comment, written by Arpit Jain on 02/03/2018 12:58:07

```go
func NewPoem(ps *PoemStorage) {
return &Poem{
storage: ps
}
}
```
Function missing return type

[christophberger]

Migrated comment, written by Christoph on 02/03/2018 14:36:25

Good catch, thanks! I fixed it now.

[christophberger]

Migrated comment, written by skovtunenko on 05/11/2018 20:49:25

Thank you, @appliedgo:disqus !

In section "Adding dependency injection" there are mistake in function signature:

func NewPoem(ps *PoemStorage) *Poem { // ps must be of type PoemStorage
return &Poem{
storage: ps
}
}


[christophberger]

Migrated comment, written by Christoph on 05/13/2018 21:14:06

Fixed. Thanks for letting me know.

[christophberger]

Migrated comment, written by MatíasC on 06/07/2018 20:10:51

Why should a poem know his storage? I'd rather locate the storing logic in the "outer ring" (the use case). Then, the injection would happen when creating the use case.

[christophberger]

Migrated comment, written by Ayenn Ul on 06/08/2018 10:53:49

Pure poetry:) Thank you very much

[christophberger]

Migrated comment, written by Christoph on 06/09/2018 15:05:43

At a first glance, it might look as if Poem knows how to store itself, but on a closer look you will discover that it doesn't. All that Poem knows is an interface with abstract load and save operations. Notebook and Napkin in the outer ring implement those load and save operations, and main() wires everything up. So the details about the storage is actually contained in the outer ring.

But why do we need the PoemStorage interface in the inner ring then? Without that interface, the outer ring wound need to access Poem directly. Notebook and Napkin would need to know the internals of Poem in order to save and load a poem. The PoemStorage interface avoids this tight coupling.

[christophberger]

Migrated comment, written by Chris Duncan on 10/19/2021 19:09:53

I also do not think Poem should contain anything beyond its content. The interface for saving a poem should not be a part of the poem struct. Instead, some third package should be glueing them together as needed.