baking delicious modularity in scala

Baking

Delicious

Modularization

in ScalaDerek Wyatt

Twitter: @derekwyattEmail: [email protected]

Thursday, December 12, 13

mailto:[email protected]


Object Oriented Modularity

OOD gives us...



OOD gives us... ClassesAbstract ClassesInterfacespublic

privateprotected

Inheritance&Composition



OOD gives us... ClassesAbstract ClassesInterfacespublic

privateprotected

C++ gave us... Multiple InheritanceJust Plain Evil Right?. . .

Inheritance&Composition


The Diamond ProblemA

B CisAis

A


The Diamond Problem

D

A

B CisAis

A

isAisA


The Diamond Problem

D

?

A

B CisAis

A

isAisA

Who initializes A?


The Diamond Problem

D

?

A

B CisAis

A

isAisA

Who initializes A?

B needs it initializedSo does C They can’t both do it!


The Diamond Problem

D

?

A

B CisAis

A

isAisA

Who initializes A?


Enter: Virtual Inheritance


The Diamond Problem

D

?

A

B CisAis

A

isAisA

Who initializes A?


Enter: Virtual InheritanceConvincing the world for decades that

Multiple Inheritance is BADThursday, December 12, 13

Java’s Solution to Multiple Inheritance

Multiple Inheritance




The powers that be just went and tossed it out





Implementing multiple interfaces and extending one abstract classis not equivalent





Implementing multiple interfaces and extending one abstract classis not equivalentImplementing the multiple interfaces is work





Implementing multiple interfaces and extending one abstract classis not equivalentImplementing the multiple interfaces is workSharing code amongst implementations is hard Compose and

delegate





Implementing multiple interfaces and extending one abstract classis not equivalentImplementing the multiple interfaces is workSharing code amongst implementations is hardInconsistencies show up very quickly and maintenance is a pain

Compose and

delegate





Implementing multiple interfaces and extending one abstract classis not equivalentImplementing the multiple interfaces is workSharing code amongst implementations is hardInconsistencies show up very quickly and maintenance is a pain

Compose and

delegate#FAIL


Scala’s Solution to Multiple Inheritance



Crush the Diamond!



Crush the Diamond!Scala integrates inheritance with mixin functionality



Crush the Diamond!Scala integrates inheritance with mixin functionalityTraits provide the construct for mixins

trait Atrait B extends Atrait C extends Aclass D extends B with C





Translates to

Any

AnyRef

A

B

C

D

Initia

lize





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

Translates to

Any

AnyRef

A

B

C

D

Initia

lize


Origins of the Cake

Randomizer

Persistence

PicRetriever DatabasePersistence

HashMap TestPersistence

RESTPersistence

RandomRandomizer

Specifier TestRandomizer

def randomPic: Future[Pic]

Dependency Injection and Modularity


Origins of the Cake

Randomizer

Persistence



RESTPersistence

RandomRandomizer




Origins of the Cake


Origins of the Cake

Randomizer

Persistence



RESTPersistence

RandomRandomizer



Declare reliance on

these modules


Origins of the Cake


Origins of the Cake

Randomizer

Persistence



RESTPersistence

RandomRandomizer



Declare reliance on

these modules

new PicRetriever extends Database with RandomChoose concrete implementations


Origins of the Cake


Origins of the Cake

Randomizer

Persistence

PicRetriever

DatabasePersistence


RESTPersistence

RandomRandomizer



Declare reliance on

these modules

new PicRetriever extends Database with RandomChoose concrete implementations


PicRetriever

mixes in the

interface

and the

implementation

Origins of the Cake


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

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



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

object PicRetriever { def production: PicRetriever = new PicRetriever with Persistence with Randomizer}


Declare PicRetri

ever

self type






Declare PicRetri

ever

self type

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.

Declare PicRetri

ever

self type

Define factory method that makes construction simpler


Adding a LayerThe lack of an “interface” requires overrides in the derivations



We can add that layer, making derivations easier to write




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

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




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

object PicRetriever { def production: PicRetriever = new PicRetriever with Database with RealRandomizer}

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


Eliminating Naming Conflicts


Eliminating Naming ConflictsThere’s nothing to stop you from tromping all over your names


Eliminating Naming ConflictsThere’s nothing to stop you from tromping all over your namesIt’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 }}





Everything can be

solved with another

layer of indirection





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


Taming the Test


trait TestRand

omizerComp ext

ends Randomize

rComponent {

val randomiz

er: Randomizer

trait TestRa

ndomizer exten

ds Randomizer

{

val i: Int

def nextIn

t(upperBound:

Int): Int = i

}}

Taming the Test


trait TestRand

omizerComp ext

ends Randomize

rComponent {

val randomiz

er: Randomizer

trait TestRa

ndomizer exten

ds Randomizer

{

val i: Int

def nextIn

t(upperBound:

Int): Int = i

}}

trait TestPersiste

nceComp extends Pe

rsistenceComponent

{

val persistence:

PersistenceCompon

ent

trait TestPersis

tence extends Pers

istence {

val pics: Vect

or[Pic]

def pic(idx: I

nt): Future[Pic] =

Future(pics(idx))

def totalPics:

Future[Int] = Fut

ure(pics.size)

}}

Taming the Test


trait TestRand

omizerComp ext

ends Randomize

rComponent {

val randomiz

er: Randomizer

trait TestRa

ndomizer exten

ds Randomizer

{

val i: Int

def nextIn

t(upperBound:

Int): Int = i

}}

trait TestPersiste

nceComp extends Pe

rsistenceComponent

{

val persistence:

PersistenceCompon

ent

trait TestPersis

tence extends Pers

istence {

val pics: Vect

or[Pic]

def pic(idx: I

nt): Future[Pic] =

Future(pics(idx))

def totalPics:

Future[Int] = Fut

ure(pics.size)

}}

Taming the Test

object TestPicRetriever { def test(num: Int, images: Vector[Pic]): PicRetriever = new PicRetriever with TestPersistenceComp with TestRandomizerComp { val persistence = new TestPersistence { val pics = images } val randomizer = new TestRandomizer { val i = num } }


trait TestRand

omizerComp ext

ends Randomize

rComponent {

val randomiz

er: Randomizer

trait TestRa

ndomizer exten

ds Randomizer

{

val i: Int

def nextIn

t(upperBound:

Int): Int = i

}}

trait TestPersiste

nceComp extends Pe

rsistenceComponent

{

val persistence:

PersistenceCompon

ent

trait TestPersis

tence extends Pers

istence {

val pics: Vect

or[Pic]

def pic(idx: I

nt): Future[Pic] =

Future(pics(idx))

def totalPics:

Future[Int] = Fut

ure(pics.size)

}}

Taming the Test

object TestPicRetriever { def test(num: Int, images: Vector[Pic]): PicRetriever = new PicRetriever with TestPersistenceComp with TestRandomizerComp { val persistence = new TestPersistence { val pics = images } val randomizer = new TestRandomizer { val i = num } }

val pic = loadPic(“pic1”)val retriever = TestPicRetriever.test(0, Vector(pic))Await.result(retriever.randomPic, 1.second) should be (pic)


Enough Analogues... Modularity!



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




Abstract types and constraints can solve the problem with greater flexibility





trait PersistenceLike { def pic(idx: Int): Future[Pic] def totalPics: Future[Int]}

trait RandomizerLike { def nextInt(upperBound: Int): Int}






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

val persistence: Persistence val randomizer: Randomizer

// ...}







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

val persistence: Persistence val randomizer: Randomizer

// ...}


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


Use Case... Configuration



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

trait Configclass DBConfig extends Config { val dbHost: String val dbPort: Int}class RandomizerConfig extends Config { val randomSeed: Int val randomScale: Int}class RESTConfig extends Config { val restHost: String val restPort: Int}




You want generality, so you can’t pass multiple configs

abstract class Component(config: Config) trait Configclass DBConfig extends Config { val dbHost: String val dbPort: Int}class RandomizerConfig extends Config { val randomSeed: Int val randomScale: Int}class RESTConfig extends Config { val restHost: String val restPort: Int}





abstract class Component(config: Config)

class Database(config: Config) extends Component(config) { require(config.isInstanceOf[DBConfig])}

class Randomizer(config: Config) extends Component(config) { require(config.isInstanceOf[RandomizerConfig])}

class REST(config: Config) extends Component(config) { require(config.isInstanceOf[RESTConfig])}






abstract class Component(config: Config)

class Database(config: Config) extends Component(config) { require(config.isInstanceOf[DBConfig])}

class Randomizer(config: Config) extends Component(config) { require(config.isInstanceOf[RandomizerConfig])}

class REST(config: Config) extends Component(config) { require(config.isInstanceOf[RESTConfig])}


Ugly, Unsafe, and

Annoying


Configuring through Inverse Generality

Database Config

REST Config

Randomization Config


Configuring through Inverse GeneralityConfig

IsAIsA

IsA

Database Config

REST Config



Configuring through Inverse GeneralityConfig Empty generalization

IsAIsA

IsA

Database Config

REST Config



Configuring through Inverse GeneralityDatabase Config

REST Config


DatabaseREST

Randomization

CONFIG OBJECT

Highly Specificand Type safe


Thickly Typed Objects Kinda stolen from Daniel Spiewak❊



trait ConfigComponent { 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 { def pic(idx: Int): Future[Pic] = ??? def totalPics: Future[Int] = ??? }

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










Define how to configure this component








Define how to configure this component

Repeat for REST and Randomizer


Thickly Typed Objects Continuedclass 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...}




The config object now conforms to the types

requested by everything that’s been mixed in.




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.


Pain and Frustration


Pain and FrustrationCakes generally involve abstract vals


Pain and FrustrationCakes generally involve abstract valsThey also involve “Multiple Inheritance”



This presents an interesting initialization problem




trait A { val s: String val t: String = s.substring(0, 2)}

trait B { val s: String = “What?”}






class C extends A with B

val c = new C






class C extends A with B

val c = new C

NPE!!!!!!


Null Pointer Exceptions?!


Null Pointer Exceptions?!We’re not used to these any more


Null Pointer Exceptions?!We’re not used to these any moreThey’re an artifact of initialization order and usage



ABC



ABC

Initialization Order



ABC


A is referencing ‘s’



ABC



‘s’ hasn’t been initialized yet!



ABC



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


Dealing with the Pain


Dealing with the PainMethods aren’t susceptible to this problem



Neither are lazy vals




Neither are constructor parameters






class B(val s) extends A

val b = new B(“What?”)








OK









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

val b = new B

OK










val b = new B

OK OK










val b = new B


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

val b = new B

OK OK










val b = new B


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

val b = new B

OKOK

OK


Now go get Fat

Derek WyattTwitter: @derekwyatt

Email: [email protected]

Eat lots of cakeAND

Maudularize Yore Coad




baking delicious modularity in scala

Technology