| /** This is in reference to @tploecat's blog http://tpolecat.github.io/2015/04/29/f-bounds.html | |
| * where he compares F-bounded polymorphism and type classes for implementing "MyType". | |
| * | |
| * Curiously, the in my mind obvious solution is missing: Use abstract types. | |
| * | |
| * A lot of this material, including an argument against F-bounded for the use-case | |
| * is discussed in: | |
| * | |
| * Kim B. Bruce, Martin Odersky, Philip Wadler: | |
| * A Statically Safe Alternative to Virtual Types. ECOOP 1998: 523-549 |
| def write(path: String, txt: String): Unit = { | |
| import java.nio.file.{Paths, Files} | |
| import java.nio.charset.StandardCharsets | |
| Files.write(Paths.get(path), txt.getBytes(StandardCharsets.UTF_8)) | |
| } | |
| def read(path: String): String = | |
| scala.io.Source.fromFile(path, "UTF-8").getLines.mkString |
| import scalaz._ | |
| import Scalaz._ | |
| import Lens._ | |
| /* | |
| Examples of Scalaz lenses | |
| */ |
#The Problem We just described standard design issues you have when you start creating layers of services, DAOs and other components to implement an application. That blog/gist is here.
The goal is to think through some designs in order to develop something useful for an application.
#Working through Layers If you compose services and DAOs the normal way, you typically get imperative style objects. For example, imagine the following:
object DomainObjects {
Standard design patterns in scala recommend the cake pattern to help compose larger programs from smaller ones. Generally, for simple cake layers, this works okay. Boner's article suggests using it to compose repository and service layers and his focus is on DI-type composition. As you abstract more of your IO layers however, you realize that you the cake pattern as described does not abstract easily and usage becomes challenging. As the dependencies mount, you create mixin traits that express those dependence and perhaps they use self-types to ensure they are mixed in correctly.
Then at the end of the world, you have to mix in many different traits to get all the components. In addition, perhaps you have used existential types and now you must have a val/object somewhere (i.e. a well defined path) in order to import the types within the service so you can write your program. Existential
##Cake Pattern and Why Cake Patterns Sometimes Look Different The cake pattern is typically described as a way to use small layers of functionality to create a larger, more complex program. This area of application design is typically designed with application scalability not in the pure performance sense, but in the sense of scaling the application up to more complex functionality and maintainability over time.
There have been many papers and blogs on this aspect, but a few especially helpful blogs include:
| import annotation.tailrec | |
| import scala.math.Ordering.Implicits._ | |
| object MergeSort { | |
| def apply[T : Numeric](xs: Seq[T]): Seq[T] = { | |
| val n = xs.length / 2 | |
| if (n == 0) | |
| xs | |
| else { |
| object test { | |
| /** | |
| * The companion object | |
| */ | |
| object Reader { | |
| /** | |
| * automatically wrap a function in a reader | |
| */ |