CPS or DI

class: center, middle

# CPS or DI

Scala Matsuri 2019 2019/06/28

<div class="translation">
継続とDI
</div>
---
class: left, middle

## Who am I

* Manabu Nakamura
* [@gakuzzzz](https://twitter.com/gakuzzzz)
* Tech to Value Co.,Ltd.  CEO
* Opt Technologies Inc. Technical advisor <img src="../images/opt_logo_1.jpg" alt="Opt Technologies" width="450" style="margin-left: 0px" /> 
* F-CODE Inc. CTO <img src="../images/f-code_logo.png" alt="f-code" height="120" style="margin-left: 0px" />

<div class="translation">
自己紹介: 中村 学<br/>Tech to Value代表 / Opt Technologies技術顧問 / F-CODE CTO
</div>

---
class: left, middle

## Introduction

Information system are solving more and more complex problems.

To solve complex problems, you need to utilize the divide and conquer approach, which divides the problem first then composes solutions.

<div class="translation">
情報システムが解決しようとする問題はますます複雑化しています。<br />
複雑な問題に解決するには、問題を分割し解を合成する分割統治のアプローチが必要です。<br />
</div>

---
class: left, middle

## Introduction

> "The ways in which one can divide up the original problem depend directly on the ways in which one can glue solutions together. "

<p style="text-align:right">from <a href="http://www.cse.chalmers.se/~rjmh/Papers/whyfp.html">Why Functional Programming Matters</a></p>

<div class="translation">
「問題を分割する方法は、解を合成する方法に依存する」とも言われます。
</div>

---
class: left, middle

## Introduction

In this session, I will talk about two approaches, “Continuation-passing style(CPS)” and “Dependency Injection(DI)”, for composing reusable modules.

I will also discuss tools for dividing and conquering while comparing these approaches.Scala is a programming language that integrates both object-oriented programming and functional programming.

<div class="translation">
このセッションでは再利用可能なモジュールを合成する手法として<br>
「継続渡しスタイル(CPS)」と「Dependency Injection(DI)」について解説し、<br>
それらを比較しながら分割統治のためのツールを考察します。
</div>

---
class: left, middle

## Structured Programming

In classical structured programming languages such as C,
A function creates a multi-layered structure by calling another function internally

<span style="font-size: 50%;">Quote from [並行プログラミングと継続モナド](https://www.slideshare.net/RuiccRail/ss-52718653?ref=http://connpass.com/event/16193/presentation/) [@ruicc](https://twitter.com/ruicc)</span>

<div class="translation">
C言語に代表されるような古典的な構造化プログラミング言語では、<br/>
ある関数が内部で別の関数を呼び出すことで多層的な構造をつくります
</div>

---
class: left, middle

## Structured Programming

In this case, the granularity that can reuse individual functions is as shown in the figure.

<div class="translation">
この際、個々の関数を再利用できる粒度は図のようになります。
</div>

---
class: left, middle

## Delegation and DI (OOPL)

In contrast, OOPL allows you to change the granularity of reuse by using delegation and DI.

<div class="translation">
これに対し、OOPLでは委譲とDIを使うことで<br/>
再利用の粒度を変えることができるようになりました。
</div>

---
class: left, middle

## Delegation and DI (OOPL)

For example, H can be switched to another implementation while reusing the same F and G.

```scala
case class F(g: G) { def f() = ... }
case class G(h: H) { def g() = ... }
case class H()     { def h() = ... }
```

```scala
// Main DI configuration
lazy val hModule = H()
lazy val gModule = G(hModule)
lazy val fModule = F(gModule)

// Test DI configuration
lazy val hModule = mock[H]
lazy val gModule = G(hModule)
lazy val fModule = F(gModule)
```

<div class="translation">
例えばFとGは同じものを再利用しつつHだけ別の実装に切り替える等が可能になります。
</div>

---
class: left, middle

## CPS (FPL)

Also, in Functional Programming language, it is possible to change the granularity of reuse by using CPS.

<div class="translation">
またFunctional Programming言語では、CPSを使うことで<br/>
再利用の粒度を変えることができるようになりました。
</div>

---
class: left, middle

## Continuation-passing style

<div class="translation">
改めてCPSとはどういったものか見ていきましょう<br/>
</div>

---
class: left, middle

## Continuation-passing style

CPS is the way of that explicitly specifies the next processing that uses the calculated value instead of returning a value.

It's hard to understand so let's look at a concrete example

<div class="translation">
継続渡しスタイルとは、<br>
関数が値を返す代わりに計算した値を使う後続処理を明示的に指定する方法です。<br/>
わかりにくいので具体例を見ていきましょう
</div>

---
class: left, middle

## Continuation-passing style

```scala
// not CPS
def multipleFiveAndPrint(v: Int): Unit = println(v * 5)
def calculateAndPrint(v: Int): Unit = multipleFiveAndPrint(v + 2)

def main(): Unit = {
  calculateAndPrint(10)
}
```

```scala
// CPS
def multipleFive[A](v: Int, k: Int => A): A = k(v * 5)
def addTwo[A](v: Int, k: Int => A): A = k(v + 2)

def main(): Unit = {
  addTwo(10, multipleFive(_, println))
}
```

---
class: left, middle

## Continuation-passing style

The function that uses the value received by this argument is called continuation.

It is called continuous passing style because it passes continuation as an argument.

```scala
// CPS
def multipleFive[A](v: Int, k: Int => A): A = k(v * 5)
def addTwo[A](v: Int, k: Int => A): A = k(v + 2)

def main(): Unit = {
  addTwo(10, multipleFive(_, println))
}
```

<div class="translation">
この引数で受け取る値を利用する関数のことを継続と呼びます。<br/>
継続を引数で渡していくため継続渡しスタイルと呼ばれるわけです。
</div>

---
class: left, middle

## Continuation-passing style

In this way, it is possible to change the granularity of reuse by passing the function which should be internally dependent on the function as an argument.

<div class="translation">
こうして本来関数が内部で依存するはずの関数を引数で渡すことにより、<br/>
再利用の粒度を変える事ができるのです。
</div>

---
class: left, middle

## Continuation-passing style

By the way, if we write this CPS natulally, nesting will be deep.

Therefore, it is possible to write in a for comprehension by defining `map` and` flatMap` with the function itself that receives and processes this continuation as a class.

<div class="translation">
ちなみにこのCPSは素直に書くとネストが多重になります。<br/>
そこでこの継続を受け取って処理を行う関数自体をクラスとし、<br/>
`map`と`flatMap`を定義することでfor式で書き下す事が可能になります。
</div>

---
class: left, middle

## Continuation-passing style

```scala
case class Cont[R, A](run: (A => R) => R) {
  def map[B](f: A => B): Cont[R, B] = 
    Cont(k => run(a => k(f(a))))
  def flatMap[B](f: A => Cont[R, B]): Cont[R, B] = 
    Cont(k => run(a => f(a).run(k)))
}
object Cont {
  def unit[R, A](a: A): Cont[R, A] = new Cont(k => k(a))
}
```

---
class: left, middle

## Continuation-passing style

```scala
def multipleFive[A](v: Int, k: Int => A): A = k(v * 5)
def addTwo[A](v: Int, k: Int => A): A = k(v + 2)
```

```scala
// not use Cont
def main(): Unit = {
  addTwo(10, multipleFive(_, println))
}
```

```scala
// use Cont
def main(): Unit = {
  val cont = for {
    m <- Cont.unit(10)
    n <- Cont(addTwo[Unit](m, _))
    l <- Cont(multipleFive[Unit](n, _))
  } yield l
  cont.run(println)
}

```

---
class: left, middle

## Dependency Injection

<div class="translation">
さて次はDIについて見ていきましょう。
</div>

---
class: left, middle

## Dependency Injection

In OOPL, it can call methods of another object in a method.

Providing the dependencies between these objects from outside is called Dependency Injection (DI).

```scala
class LoginService(userDao: UserDao) { // depends on UserDao

def authenticate(id:LoginId, pass:PlainPassword):Option[User]=
    for {
      user <- userDao.findByLoginId(id) // other object's method
      if user.hashedPassword == pass.hash
    } yield user

}
```

<div class="translation">
OOPLでは、あるメソッド内で別のオブジェクトのメソッドを呼び出す事ができます。<br/>
このオブジェクト同士の依存関係を外部から与えることを、<br/>
Dependency Injection(DI) と呼びます。
</div>

---
class: left, middle

## Dependency Injection

The same implementation can be reused by receiving dependent UserDao entities from the outside.

```scala
class LoginService(userDao: UserDao) { // depends on UserDao

def authenticate(id:LoginId, pass:PlainPassword):Option[User] =
  ...
```

```scala
// Main DI configuration
lazy val userDao: UserDao = new UserDaoImpl
lazy val loginService: LoginService = new UserService(userDao)

// Test DI configuration
lazy val userDao: UserDao = mock[UserDao]
lazy val loginService: LoginService = new UserService(userDao)
```

<div class="translation">
依存するUserDaoの実体を外部から渡せるようにすることで同じ実装を再利用できます。
</div>

---
class: left, middle

## Dependency Injection

If the dependency on UserDao is internally completed,
The implementation can not be reused.

```scala
class LoginService {

// depends on UserDao
  private val userDao: UserDao = new UserDaoImpl

def authenticate(id:LoginId, pass:PlainPassword):Option[User] =
  ...
```

<div class="translation">
もし仮に、UserDaoへの依存が内部で完結していた場合、<br/>
実装を再利用することができません。
</div>

---
class: left, middle

## Dependency Injection

In this way, DI makes objects loosely coupled, and can change the granularity of reuse.

<div class="translation">
このようにDIすることによって、オブジェクト同士が疎結合になり、<br>
再利用の粒度を変える事ができるのです。
</div>

---
class: left, middle

## Which should use in Scala?

Scala is a language that realizes the integration of OOP and FP by expressing the function of FP on OOPL.

So we can easily use both CPS and DI in Scala.

<div class="translation">
ScalaはOOPLの上にFPの機能を表現することで<br/>
OOPとFPの統合を実現した言語です<br/>
従って、ScalaではCPSもDIもどちらも簡単に利用することができます。
</div>

---
class: left, middle

## Which should use in Scala?

<div class="translation">
ではCPSとDIのどちらを使うべきなのでしょうか？
</div>

---
class: left, middle

## Strongly related multiple processes

<div class="translation">
相互に強く関連する複数の処理に依存したい場合
</div>

---
class: left, middle

## Strongly related multiple processes

When we want to use multiple processes that are strongly related to each other, 
CPS can not express the relevance of multiple continuations

```scala
class LoginService(userDao: UserDao) {

def authenticate(id:LoginId, pass:PlainPassword):Option[User]=
    for {
      user <- userDao.findByLoginId(id)
      if user.hashedPassword == pass.hash
    } yield {
      if (user.hashedPassword.isAlgorithmOld) {
        val newPass = pass.hash(CurrentHashAlgorithm)
        userDao.updatePassword(user.id, newPass)
      }
      user
    }
}

```

<div class="translation">
相互に強く関連する複数の処理に依存したい場合、<br/>
CPSでは複数の継続の関連性を表現することができません<br/>
</div>

---
class: left, middle

## Strongly related multiple processes

`findByLoginId` and `updatePassword` are strongly related.

```scala
class LoginService(userDao: UserDao) {

```

<div class="translation">
findByLoginId と updatePassword は強く関連しています。
</div>

---
class: left, middle

## Strongly related multiple processes

If this is expressed in CPS, it will receive two functions, but we can not guarantee that each is a related function.

```scala
  def authenticate(
     id: LoginId, 
     pass: PlainPassword,
     findByLoginId: UserId => Option[User]
     updatePassword: (UserId, HashedPassword) => Unit
  ): Option[User] = {
    ...
  }
```

<div class="translation">
これをCPSで表現する場合、二つの関数を受け取る形になりますが、<br/>
それぞれが関連した関数であることを保証できません
</div>

---
class: left, middle

## Strongly related multiple processes

On the other hand, in OOP, it is possible to associate multiple strongly related operations in units of objects.

Therefore, when several dependent processes are strongly related, it seems that DI is better than CPS.

```scala
trait UserDao {

def findByLoginId(id: UserId): Option[User]

def updatePassword(id: UserId, pass: HashedPassword): Unit

}
```

<div class="translation">
それに対しOOPでは強く関連する複数の処理を<br/>
オブジェクトという単位で関連付けることが可能です。<br/>
従って依存する複数の処理が強く関連性を持っている場合、<br/>
CPSよりDIの方が向いているように思われます。<br/>
</div>

---
class: left, middle

## Ad-hoc composition

<div class="translation">
アドホックな処理合成
</div>

---
class: left, middle

### Ad-hoc composition

Whether CPS or DI, the process to be reused and the description for its composition are separated.

In Scala, DI composition can be realized using mixin etc. However, in general, a framework for DI is often used.

In that case, it will be a big deal if you try to control multiple dependency graphs by creating an instance of DI Container for each detailed process.

<div class="translation">
CPSにしてもDIにしても、再利用する処理とその合成のための記述が分離されます。<br/>
ScalaではDIの合成をmixin等を使っても実現できますが、<br/>
一般的にはDI用のフレームワークを用いる事が多いです。<br/>
その場合、細かな処理毎にDI Container のインスタンスを作り<br/>
複数の依存グラフをアドホックに制御しようとすると大掛かりになります。
</div>

---
class: left, middle

## Ad-hoc composition

On the other hand, CPS can be composed using for expressions.

```scala
    val foo = for {
      in     <- Close(new FileInputStream(
                        getClass.getResource("/source.txt").getPath))
      reader <- Close(new InputStreamReader(in, "UTF-8"))
      buff   <- Close(new BufferedReader(reader))
      out    <- Close(new FileOutputStream("dest.txt"))
      writer <- Close(new OutputStreamWriter(out, "UTF-8"))
    } yield {
      ...
      "hello"
    }
```

<span style="font-size: 50%;">Quote from [Loan パターンのネストは継続モナドでシュッと解決できるよという話](https://qiita.com/jwhaco/items/224113324fd454b8ca77) [@jwhaco](https://twitter.com/jwhaco)</span>

<div class="translation">
それに対しCPSではfor式をつかって合成することができます。<br/>
</div>

---
class: left, middle

## Ad-hoc composition

Resource management, Web application Filter, etc.
When recomposing common processing to ad hoc and using it
It seems to be easier to use than DI.

<span style="font-size: 60%;">ref [Loan パターンのネストは継続モナドでシュッと解決できるよという話](https://qiita.com/jwhaco/items/224113324fd454b8ca77) (Story that nest of Loan pattern can be solved by continuation monad) [@jwhaco](https://twitter.com/jwhaco)</span>

<span style="font-size: 60%;">ref [継続モナドを使ってWebアプリケーションのコントローラーを自由自在に組み立てる](https://qiita.com/pab_tech/items/fc3d160a96cecdead622) (Assembling web application controllers freely using continuation monad) [@pab_tech](https://twitter.com/pab_tech)</span>

<div class="translation">
リソース管理やWebアプリケーションのFilterなど、<br/>
共通の処理をアドホックに組み替えて利用する場合に<br/>
DIよりも手軽に利用しやすいと思われます。
</div>

---
class: middle

## Summary

* There are CPS and DI as composing methods to change module reuse unit.
* In Scala, we can use both CPS and DI easily.
* DI is recommended when we want to rely on multiple related processes or when you want to control the entire system.
* CPS is recommended when we want to use ad hoc and processing in combination.
* Let's know both FP and OOP methods and can choose a more appropriate option

<div class="translation">
・モジュールの再利用粒度を変える合成方法としてCPSとDIがあります<br/>
・ScalaではCPSとDIのどちらも手軽に使えます<br/>
・関連する複数の処理に依存したい時やマクロにシステム全体を統制したい場合はDIがおすすめ<br/>
・ミクロな単位でアドホックに処理を組み合わせて使いたい場合はCPSがおすすめ<br>
・OOP/FPどちらの由来の手法も知って、より適切な選択肢を選べるようになりましょう
</div>

---
class: left, middle

## Advertising (to Japanese)

Opt Technologies ではエンジニアを募集しています

* [Opt Technologies 採用情報](https://www.opt.ne.jp/opttechnologies/index.html#recruit)

エフ・コードではエンジニアを募集しています

* [エフ・コード 採用情報](https://f-code.co.jp/recruit/engineer.html)
---
class: middle

## Any questions?