Baking Delicious Modularity in Scala

Baking

Delicious

Modularization

cala
in S

Derek Wyatt
Twitter: @derekwyatt
Email: derek@derekwyatt.org

Thursday, December 12, 13

odularity
Oriented M
Object
OOD gives us...


odularity
Oriented M
Object
OOD gives us...


private
Inheritance
Clanc erfaces
I sist s&ro ses
ubl e p tlas
p
Cected
Composition
act
str
Ab

odularity
Oriented M
Object
OOD gives us...

C++ gave us...


private
Inheritance
Clanc erfaces
I sist s&ro ses
ubl e p tlas
p
Cected
Composition
act
str
Ab

ht?
R ig
...
l

Ev i
Multiple Inheritance
lain
st P
Ju

d Problem
he Diamon
T
is

A

B

is

A

A

C

d Problem
he Diamon
T
A

is

is

A

A

C

A

is


D

is
A

B

d Problem
he Diamon
T
A
A

is

is

A

?

B

A

is


D

C
is
A

Who initializes A?

d Problem
he Diamon
T
A
is

A

D

C
is
A

A


?

B
is

They can’t both do it!

is

l d
s it initiaoizeoes C
B need
S d

A

Who initializes A?

d Problem
he Diamon
T
A
is

A


D

C
is
A

A

Enter: Virtual Inheritance

?

B
is


is

l d
B need
S d

A

Who initializes A?

d Problem
he Diamon
T
A
is

A

?
A

D

C
is
A

B
is


is

l d
B need
S d

A

Who initializes A?

Enter: Virtual Inheritance
Convincing the world for decades that
Multiple Inheritance is BAD

Inheritance
to Multiple
’s Solution
Java



Inheritance
to Multiple
’s Solution
Java

The powers that be just went and tossed it out


Inheritance
to Multiple
’s Solution
Java

Implementing multiple interfaces and extending one abstract class
is not equivalent


Inheritance
to Multiple
’s Solution
Java

is not equivalent
Implementing the multiple interfaces is work


Inheritance
to Multiple
’s Solution
Java

is not equivalent
and
ose e
mp gat
Sharing code amongst implementations is hard Co le
de


Inheritance
to Multiple
’s Solution
Java

is not equivalent
and
ose e
mp gat
de
Inconsistencies show up very quickly and maintenance is a pain

Inheritance
to Multiple
’s Solution
Java

L
I
A
F
#



is not equivalent
and
ose e
mp gat
de
Inconsistencies show up very quickly and maintenance is a pain

nheritance
to Multiple I
a’s Solution
Scal


nheritance
to Multiple I
a’s Solution
Scal

!

Crush the Diamond


nheritance
to Multiple I
a’s Solution
Scal

!

Crush the Diamond

Scala integrates inheritance with mixin functionality


nheritance
to Multiple I
a’s Solution
Scal

!

Crush the Diamond

Traits provide the construct for mixins
trait
trait
trait
class


A
B extends A
C extends A
D extends B with C

nheritance
to Multiple I
a’s Solution
Scal

!

Crush the Diamond

trait
trait
trait
class

A
B extends A
C extends A
D extends B with C

AnyRef
A

Translates to

B
C
D


Initialize


Any

nheritance
to Multiple I
a’s Solution
Scal

!

Crush the Diamond

trait
trait
trait
class

A
B extends A
C extends A
D extends B with C

A

Translates to

If a conflict exists between B and C with respect
to A, then C wins.

AnyRef

B
C
D

Initialize


Any

Origins of the Cake
Dependency Injection and Modularity

Persistence

REST
Persistence

PicRetriever

Database
Persistence

Persistence
Randomizer
def randomPic: Future[Pic]

HashMap

Randomizer

Random
Randomizer

Specifier


Test

Test

Origins of the Cake

Persistence

REST
Persistence

PicRetriever

ce on
lian
re re
Decla modules
hese
t

Database
Persistence

Persistence
Randomizer

HashMap

Randomizer

Random
Randomizer

Specifier


Test

Test

Origins of the Cake

Persistence

REST
Persistence

PicRetriever

ce on
lian
re re
Decla modules
hese
t

Persistence

Persistence
Randomizer

new PicRetriever extends Database
with Random
Choos

e concrete
implementa
tions

Database
HashMap

Test

Randomizer

Random
Randomizer

Specifier

Test

Origins of the Cake

REST

PicRetriever

ce on
lian
re re
Decla modules
hese
t

Persistence

Persistence
Database

Randomizer

Randomizer
Random

Persistence

iever
Retr
Pic
the Persistence
es in
Test
mix
HashMap
face
ter
in
the
and
tion
enta
plem
im


new PicRetriever extends Database
with Random
Choos

e concrete
implementa
tions

Randomizer

Specifier

Test

The Basic Cupcake
trait Persistence {
def pic(idx: Int): Future[Pic] = ???
def totalPics: Future[Int] = ???
}


trait Randomizer {
def nextInt(upperBound: Int): Int = ???
}

The Basic Cupcake
trait Persistence {
}

trait Randomizer {
}

cRe
Pi

ever
tri

lare
Dec
ype
elf t
s

class PicRetriever { this: Persistence with Randomizer =>
def randomPic: Future[Pic] = ???
}
object PicRetriever {
def production: PicRetriever = new PicRetriever
with Persistence with Randomizer
}


The Basic Cupcake
trait Persistence {
}

trait Randomizer {
}

cRe
Pi

ever
tri

lare
Dec
ype
elf t
s

}

Define factory method that
makes construction simpler

}


The Basic Cupcake
trait Persistence {
}

trait Randomizer {
}

cRe
Pi

ever
tri

lare
Dec
ype
elf t
s

}

Define factory method that
makes construction simpler

}

You could derive new Persistence and Randomizer traits and
instantiate accordingly. Not great, but it does get the job done.

ng a Layer
Addi
The lack of an “interface” requires overrides in the derivations


ng a Layer
Addi
We can add that layer, making derivations easier to write


ng a Layer
Addi
trait
def
def
}
trait
val
def
def
}

Persistence {
pic(idx: Int): Future[Pic]
totalPics: Future[Int]
Database extends Persistence {
dbUrl: String
pic(idx: Int): Future[Pic] = ???
totalPics: Int = ???


trait
def
}
trait
def
}

Randomizer {
nextInt(upperBound: Int): Int
RealRandomizer extends Randomizer {
nextInt(upperBound: Int): Int = ???

ng a Layer
Addi
trait
def
def
}
trait
val
def
def
}

Persistence {
pic(idx: Int): Future[Pic]
totalPics: Future[Int]
Database extends Persistence {
dbUrl: String
pic(idx: Int): Future[Pic] = ???
totalPics: Int = ???

trait
def
}
trait
def
}

Randomizer {
nextInt(upperBound: Int): Int
RealRandomizer extends Randomizer {
nextInt(upperBound: Int): Int = ???

with Database with RealRandomizer
}

Eliminating Naming Conflicts


There’s nothing to stop you from tromping all over your names


It’s a good idea to give namespaces to the mixed-in modules
trait PersistenceComponent {
val persistence: Persistence
trait Persistence {
def pic(idx: Int): Future[Pic]
def totalPics: Future[Int]
}
}


trait RandomizerComponent {
val randomizer: Randomizer
trait Randomizer {
def nextInt(upperBound: Int): Int
}
}

trait Persistence {
}
}

trait Randomizer {
}
}

g can be
Everythin
th another
solved wi
indirection
layer of

trait Persistence {
trait Randomizer {
}
}
}
}
class PicRetriever { this: PersistenceComponent with RandomizerComponent =>
// ...
}
def production: PicRetriever = new PicRetriever with ProdPersistence
with ProdRandomizer {
val persistence = new Persistence { }
val randomizer = new Randomizer { }
}

he Test
aming t
T


he Test
aming t
T

ze
ndomi
Ra

r

t
ponen
Com

ds
exten
p
{
erCom zer
izer
miz
om
i
do
stRan r: Random tends Rand
Te
e
rait
t
domiz omizer ex
i
an
nt =
val r estRand
I
Int):
t T
:
trai
Int
Bound
r
:
val i tInt(uppe
ex
def n
}
}


{

he Test
aming t
T

ze
ndomi
Ra

r

t
ponen
Com

{

ds
exten
p
{
erCom zer
izer
miz
om
i
do
{
Te
ponent
om
trait andomize mizer ex
tenceC
i
is
nt =
val r estRando
s Pers
I
nd
p exte mponent
Int):
t T
:
Com
trai
{
Int
Bound
stence istenceCo
i:
per
tence
ersi
is
up
tP
val
tInt(
it Tes stence: Pers extends Pers
ex
tra
))
def n
cs(idx
persi
ence
pi
st
val
uture( ize)
tPersi r[Pic]
es
= F
}
.s
rait T s: Vecto
[Pic]
t
ture
e(pics
u
r
c
val pi idx: Int): F [Int] = Futu
}
(
ef pic Pics: Future
d
l
f tota
de

}
}


he Test
aming t
T

ze
ndomi
Ra

r

t
ponen
Com

{

ds
exten
p
{
erCom zer
izer
miz
om
i
do
{
Te
ponent
om
tenceC
i
is
nt =
val r estRando
s Pers
I
nd
p exte mponent
Int):
t T
:
Com
trai
{
Int
Bound
stence istenceCo
i:
per
tence
ersi
is
up
tP
val
tInt(
ex
tra
))
def n
cs(idx
persi
ence
pi
st
val
uture( ize)
tPersi r[Pic]
es
= F
}
.s
rait T s: Vecto
[Pic]
t
ture
e(pics
u
r
c
val pi idx: Int): F [Int] = Futu
}
(
ef pic Pics: Future
d
l
f tota
de

}

object TestPicRetriever
}
{
def test(num: Int, images
: Vector[Pic]): PicRetri
ever =
new PicRetriever with Te
stPersistenceComp
with TestRandomizerComp
{
val persistence = new Te
stPersistence { val pics
= images }
val randomizer = new Test
Randomizer { val i = num
}
}


he Test
aming t
T

ze
ndomi
Ra

r

t
ponen
Com

{

ds
exten
p
{
erCom zer
izer
miz
om
i
do
{
Te
ponent
om
tenceC
i
is
nt =
val r estRando
s Pers
I
nd
p exte mponent
Int):
t T
:
Com
trai
{
Int
Bound
stence istenceCo
i:
per
tence
ersi
is
up
tP
val
tInt(
ex
tra
))
def n
cs(idx
val pic = loadPic(“pic1”) rsi
pe
ence
pi
st
val
uture( ize)
tPersi r[Pic]
es
]
val retriever = TestPicRetriever.test(0, Vector(pic))= F pics.s
}
rait T s: Vecto
t
re[Pic ture(
u
Await.result(retriever.randomPic,:1.second)t should be (pic)
l pic
t): Fu nt] = Fu
va
In
}
I
(idx
pic
uture[
F
def
lPics:
ta
def to
}
object TestPicRetriever
}
{
def test(num: Int, images
: Vector[Pic]): PicRetri
ever =
new PicRetriever with Te
stPersistenceComp
with TestRandomizerComp
{
val persistence = new Te
stPersistence { val pics
= images }
val randomizer = new Test
Randomizer { val i = num
}
}


nough Analogues... Modularity!
E


E
You don’t have to “self type” in order to establish the contract


E
Abstract types and constraints can solve the problem with greater flexibility


E
trait PersistenceLike {
}


trait RandomizerLike {
}

E
}

}

trait PicRetriever {
type Persistence <: PersistenceLike
type Randomizer <: RandomizerLike
}


// ...

E
}

Abstract types define
enough to work with for the
PicRetriever, but allow for
further specification later

}

trait PicRetriever {
type Persistence <: PersistenceLike
type Randomizer <: RandomizerLike
}

// ...

Use Case... Configuration


Let’s say you want to declare a method for configuring objects

trait
class
val
val
}
class
val
val
}
class
val
val
}


Config
DBConfig extends Config {
dbHost: String
dbPort: Int
RandomizerConfig extends Config {
randomSeed: Int
randomScale: Int
RESTConfig extends Config {
restHost: String
restPort: Int

You want generality, so you can’t pass multiple configs
abstract class Component(config: Config)


trait
class
val
val
}
class
val
val
}
class
val
val
}

Config
DBConfig extends Config {
dbHost: String
dbPort: Int
RandomizerConfig extends Config {
randomSeed: Int
randomScale: Int
RESTConfig extends Config {
restHost: String
restPort: Int


trait Config
class DBConfig extends Config {
val dbHost: String
class Database(config: Config) extends Component(config) ort: Int
val dbP {
require(config.isInstanceOf[DBConfig])
}
}
class RandomizerConfig extends Config {
val randomSeed: Int
val randomScale: Int
class Randomizer(config: Config) extends Component(config) {
}
require(config.isInstanceOf[RandomizerConfig]) ss RESTConfig extends Config {
cla
}
val restHost: String
val restPort: Int
}
class REST(config: Config) extends Component(config) {
require(config.isInstanceOf[RESTConfig])
}


d
an

e,
af
s
n
,U
g
ly
in
g
U
oy
n
n
A


trait Config
class DBConfig extends Config {
val dbHost: String
class Database(config: Config) extends Component(config) ort: Int
val dbP {
require(config.isInstanceOf[DBConfig])
}
}
class RandomizerConfig extends Config {
val randomSeed: Int
val randomScale: Int
class Randomizer(config: Config) extends Component(config) {
}
require(config.isInstanceOf[RandomizerConfig]) ss RESTConfig extends Config {
cla
}
val restHost: String
val restPort: Int
}
class REST(config: Config) extends Component(config) {
require(config.isInstanceOf[RESTConfig])
}

ring through Inverse Generality
Configu

Database
Config


REST
Config

Randomization
Config

Configu
Config

sA
I
Database
Config


IsA
REST
Config

IsA
Randomization
Config

Configu
Config

sA
I
Database
Config


IsA
REST
Config

Empty generalization

IsA
Randomization
Config

Configu
Database
Config

Randomization
Config

REST
Config

Da

REST

iz
m

ti
a

n
o

CONFIG OBJECT
ba
do
s
ta

e

an
R

Highly Specific
and Type safe

Thickly Typed Objects


❊
Kinda stolen from Daniel Spiewak

trait ConfigComponent {
type Config
def config: Config
}


❊

Declare a way to
configure things

type Config
def config: Config
}

❊

Declare a way to
configure things

trait DBComponent extends PersistenceComponent with ConfigComponent {
type Config <: DBConfig
val persistence = new DB
class DB extends Persistence {
}

}

trait DBConfig {
val dbHost: String
val dbPort: Int
}


type Config
def config: Config
}

❊

Declare a way to
configure things

}

}

trait DBConfig {
val dbHost: String
val dbPort: Int
}


Define how to configure
this component

type Config
def config: Config
}

❊

Declare a way to
configure things

Repeat for REST and
Randomizer

}

}

trait DBConfig {
val dbHost: String
val dbPort: Int
}


Define how to configure
this component

Typed Objects Continued
Thickly
class TheFinalThing extends DBComponent with RandomizerComponent
with RESTComponent {
type Config = DBConfig with RESTConfig with RandomzierConfig

}

object config extends DBConfig with RESTConfig
with RandomzierConfig {
val dbHost = “dbhost1”
val dbPort = 56872
val restHost = “resthost1”
val restPort = 8080
val randomSeed = System.currentTimeMillis.toInt
val randomScale = 6
}
// etc...


Thickly

}

val dbPort = 56872
val restPort = 8080
val randomScale = 6
}
// etc...


The config object now
conforms to the types
requested by everything
that’s been mixed in.

Thickly

}

val dbPort = 56872
val restPort = 8080
val randomScale = 6
}
// etc...


The config object now
conforms to the types
requested by everything
that’s been mixed in.
Each Component can access the fields of
their slice of the config object without the
need for casting. The compiler already
knows it’s right.

n and Frustration
ai
P


n and Frustration
ai
P
Cakes generally involve abstract


vals

n and Frustration
ai
P

vals

They also involve “Multiple Inheritance”


n and Frustration
ai
P

vals

This presents an interesting initialization problem


n and Frustration
ai
P

vals

trait A {
val s: String
val t: String = s.substring(0, 2)
}
trait B {
val s: String = “What?”
}


n and Frustration
ai
P

vals

trait A {
val s: String
}
trait B {
}


class C extends A with B
val c = new C

n and Frustration
ai
P

vals

trait A {
val s: String
}
trait B {
}


PE
N

!!
!!!
!
class C extends A with B
val c = new C

Null Pointer Exceptions?!


We’re not used to these any more


They’re an artifact of initialization order and usage



A
B
C



Initialization Order

A
B
C




A
B
C

A is referencing ‘s’




A
B
C

‘s’ hasn’t been initialized yet!




A
B
C

‘s’ hasn’t been initialized yet!
The only sane value for ‘s’ at
this point is null

Dealing with the Pain


Methods aren’t susceptible to this problem


Neither are lazy vals


Neither are constructor parameters


trait A {
val s: String
}
class B(val s) extends A
val b = new B(“What?”)


trait A {
val s: String
}

OK



trait A {
val s: String
}

trait A {
val s: String
}


class B extends A {
lazy val s = “What?”
}

OK


val b = new B


trait A {
val s: String
}

trait A {
val s: String
}


class B extends A {
}

OK


OK

val b = new B


trait A {
trait A {
val s: String
val s: String
trait A {
}
}
val s: String
class B extends A {
class B(val s) extends} A
val b = new B(“What?”)class B extends A { }
def s = “What?”
val b = new B
}

OK

OK

val b = new B

trait A {
trait A {
val s: String
val s: String
trait A {
}
}
val s: String
class B extends A {
class B(val s) extends} A
val b = new B(“What?”)class B extends A { }
def s = “What?”
val b = new B
}

OK

OK

val b = new B

OK

Now go get Fat

Eat lots of cake

AND

audularize Yore Coad
M
Derek Wyatt
Twitter: @derekwyatt
Email: derek@derekwyatt.org

Baking Delicious Modularity in Scala

Recommended

Recommended

More Related Content

Similar to Baking Delicious Modularity in Scala

Similar to Baking Delicious Modularity in Scala (20)

Recently uploaded

Recently uploaded (20)

Baking Delicious Modularity in Scala