S.O.L.I.D. principles with Scala. There are five basic principles of object-oriented programming and design. When applied together intend to make it more likely that a programmer will create a system that is easy to maintain and extend over time.

1. S.O.L.I.D with Scala
Oct 23' 2012 > Vikas Hazrati > vikas@knoldus.com > @vhazrati

2. what?
Five basic principles of object-oriented
programming and design.
When applied together intend to make it more likely that
a programmer will create a system that is easy
to maintain and extend over time.

3. problems
rigid – difficult to add new features
fragile – unable to identify the impact of the change
immobile – no reusability
viscous – going with the flow of bad practices already
being present in the code.

4. solutions
loosely coupled – shouldn’t be too much of
dependency between the modules, even if there is a
dependency it should be via the interfaces and should
be minimal.
cohesive code- The code has to be very specific in its
operations.
context independent code- so that it can be reused.
DRY – Don't repeat yourself – Avoid copy-paste of
code. Change in the code would have to be made in
all the places where its been copied.

6. single responsibility principle - srp
a module should have only one reason to change
Avoid side effects Minimize code Increase re-usability
touch-points
Separate out different responsibilities into different code units

7. package com.knolx
trait UserService {
def changeEmail
}
class SettingUpdateService extends UserService {
def changeEmail ={
checkAccess match {
case Some(x) => // do something
case None => //do something else
}
}
def checkAccess:Option[Any] = None
}

8. class task{
def downloadFile = {}
def parseFile = {}
def persistData = {}
}

9. for scala
srp applies to
functions
data structures
packages/ modules of functions

10. open closed principle - ocp
A module should be open for extension but
closed for modification
Avoid side effects Minimize code
touch-points

11. case class Check(id:Int, bankName:String,
amount:Double)
class CheckProcessor {
val checkList:List[Check] = List(new Check(1,
"BoA", 200.0))
def checkProcessor = sendEmail
def sendEmail = {}
}

12. case class Check(id:Int, bankName:String, amount:Double)
class CheckProcessor {
val checkList:List[Check] = List(new Check(1, "BoA",
200.0), new Check(2, "Citi", 100.0))
def checkProcessor = for (check <-checkList) if
(check.bankName == "BoA") sendEmail else sendFax
def sendEmail = {}
def sendFax = {}
}

13. trait BankProcess{
def processCheck
}
class BoABank(name:String) extends BankProcess{
def processCheck = sendEmail
def sendEmail = {}
}
class CitiBank(name:String) extends BankProcess{
def processCheck = sendFax
def sendFax = {}
}
case class Check(id:Int, bank:BankProcess, amount:Double)
class CheckProcessor {
val checkList:List[Check] = List(new Check(1, new
BoABank("BoA"), 200.0), new Check(2, new CitiBank("Citi"),
100.0))
def checkProcessor = for (check <-checkList)
check.bank.processCheck
}

14. interface segregation principle - isp
many specific interfaces are better than one
general purpose interface
Avoid side effects Increase re-usability

15. trait DoorService{
def isOpen
def open
def close
}
class Door extends DoorService{
def isOpen = {}
def open = {}
def close = {}
}

16. trait DoorService{
def isOpen
def open
def close
}
trait TimerDoorService{
def closeAfterMinutes(duration:Int)
}
class Door extends DoorService{
def isOpen = {}
def open = {}
def close = {}
}
class TimerDoor extends DoorService with TimerDoorService{
def isOpen = {}
def open = {}
def close = {}
def closeAfterMinutes(duration:Int) = {}
}

17. dependency inversion principle - dip
depend on abstractions, not on concretions
Avoid side effects reduced effort for Increase re-usability
adjusting to existing
code changes

18. class TwitterProcessor {
def processTweets = new Processor.process(List("1","2"))
}
class Processor {
def process(list:List[String]) = {}
}

19. trait ProcessorService {
def process(list:List[String])
}
class TwitterProcessor {
val myProcessor:ProcessorService = new Processor
def processTweets = myProcessor.process(List("1","2"))
}
class Processor extends ProcessorService{
def process(list:List[String]) = process(list, true)
def process(list:List[String], someCheck:Boolean) = {}
}

20. for scala
becomes less relevant for Scala as we can
pass higher order functions to achieve the same
behavior

21. liskov substitution principle - lsp
subclasses should be substitutable for their base
classes
Avoid side effects
a derived class is substitutable for its base class if:
1. Its preconditions are no stronger than the base class method.
2. Its postconditions are no weaker than the base class method.
Or, in other words, derived methods should expect no more and provide no less

22. trait DogBehavior{
def run
}
class RealDog extends DogBehavior{
def run = {println("run")}
}
class ToyDog extends DogBehavior{
val batteryPresent = true
def run = {
if (batteryPresent) println("run")
}
}
object client {
def runTheDog(dog:DogBehavior) = {dog.run}
}

23. object client2 {
def runTheDog(dog:DogBehavior) = {if (dog.isInstanceOf[ToyDog] )
dog.asInstanceOf[ToyDog].batteryPresent=true; dog.run}
}
violates
ocp
now