Update: removed custom flatMap in favor of scalaz's Reader
As Travis already pointed out, to use the Reader pattern, you need single argument functions. So in order to use it for multiple dependencies, you somehow need to get all of your dependencies into a single argument. And here it becomes interesting. The way Travis showed is the simplest way to do it, but you also have to manually switch environments using the .local calls and if you need multiple dependencies for subtrees of your computation, you need to manually build local environments.
Another way to to it is to let Scala's subtyping figure it out auto-magically. As long as your dependencies can be mixed in, composing things with different or multiple dependencies just works (if you actually use scalaz's Reader, not if you use flatMap on Function1 as some of the Reader examples do).
Option 1: Cup cake pattern
One way to allow your dependencies to be able to mixed in is a stripped down cake pattern. I'd call it cup-cake pattern, if I had to give it a name, Dick Wall calls it Parfait (see https://parleys.com/play/53a7d2cde4b0543940d9e55f/chapter28/about ). The idea is instead of putting everything into the cake, only put the dependencies into the cake and pass it through as a context object, which you can abstract over using the reader. Let's apply it to your example:
// business logic
class PageFetcher {
def fetch(url: String) = Reader((deps: Dep1Component) => Try {
...
})
}
class ImageExtractor {
def extractImages(html: String) = Reader((deps: (Dep2Component with Dep3Component)) => {
...
})
}
object MyImageFinder {
def find(url: String) =
for {
pageFetcher <- Reader((deps: PageFetcherComponent) => dep.pageFetcher)
imageExtractor <- Reader((deps: ImageExtractorComponent) => dep.imageExtractor)
htmlTry <- pageFetcher.fetch(url)
html <- htmlTry
images <- imageExtractor.extractImages(html)
} yield images
}
// I add these 3 useless dependencies here just for demo
class Dep1
class Dep2
class Dep3
// cupcake modules
trait PageFetcherComponent{
def pageFetcher: PageFetcher
}
trait ImageExtractorComponent{
def imageExtractor: ImageExtractor
}
trait Dep1Component{
def dep1: Dep1
}
trait Dep2Component {
def dep2: Dep2
}
trait Dep3Component{
def dep3: Dep3
}
object Dependencies extends PageFetcherComponent with ImageExtractorComponent with Dep1Component with Dep2Component with Dep3Component{
val pageFetcher = new PageFetcher
val imageExtractor = new ImageExtractor
val dep1 = new Dep1
val dep2 = new Dep2
val dep3 = new Dep3
}
def main(args: Array[String]) {
args.headOption match {
case Some(url) =>
MyImageFinder.find(url)(Dependencies) match {
case Success(images) => images.foreach(println)
case Failure(err) => println(err.toString)
}
case _ => println("Please input an url")
}
}
The cup-cake pattern becomes tricky if you have multiple instances of the same dependencies (multiple loggers, multiple dbs, etc.) and have some code which you want to be able to selectively use on the one or the other.
Option 2: Type-indexed Map
I recently came up with another way to do it using a special data structure I call type-indexed map. It saves all the cup-cake boiler plate and it makes it much easier to use multiple instances of the same type of dependency (i.e. just wrap them in single member classes to distinguish them).
/** gets stuff out of a TMap */
def Implicit[V:TTKey] = Reader((c: TMap[V]) => c[V])
// business logic
class PageFetcher {
def fetch(url: String) = Implicit[Dep1].map{ dep1 => Try {
...
}}
}
class ImageExtractor {
def extractImages(html: String) = for{
dep2 <- Implicit[Dep1]
dep3 <- Implicit[Dep3]
} yield {
...
}
}
object MyImageFinder {
def find(url: String) =
for {
pageFetcher <- Implicit[PageFetcherComponent]
imageExtractor <- Implicit[ImageExtractorComponent]
htmlTry <- pageFetcher.fetch(url)
html <- htmlTry
images <- imageExtractor.extractImages(html)
} yield images
}
// I add these 3 useless dependencies here just for demo
class Dep1
class Dep2
class Dep3
val Dependencies =
TMap(new PageFetcher) ++
TMap(new ImageExtractor) ++
TMap(new Dep1) ++
TMap(new Dep2) ++
TMap(new Dep3)
def main(args: Array[String]) {
args.headOption match {
case Some(url) =>
MyImageFinder.find(url)(Dependencies) match {
case Success(images) => images.foreach(println)
case Failure(err) => println(err.toString)
}
case _ => println("Please input an url")
}
}
I published it here https://github.com/cvogt/slick-action/ . The corresponding test cases are here: https://github.com/cvogt/slick-action/blob/master/src/test/scala/org/cvogt/di/TMapTest.scala#L213 It's on maven, but be careful when using it, because the code is in flux and the current implementation is not thread-safe in 2.10, only in 2.11, because it relies on TypeTags. I'll probably publish a version that works for 2.10 and 2.11 at some point.
Addendum
While this solves multi-dependency injection with the reader monad, you will still get type errors for htmlTry because you are mixing Reader/Function1-composition with Try-composition. The solution is to create a wrapping Monad that internally wraps Function1[TMap[...],Try[...]] and allow composing those. This does require you to stuff everything into this type of monad, even if something wouldn't need a Try.
