Modular programming Using Object in Scala

Modular Programming
Using Object in Scala

Ruchi Jindal
Software Consultant
Knoldus

Scala's Strength
 Agile, with lightweight syntax

 Scala is a pure object-oriented language

 Functional Programming

 Safe and performant, with strong static typing

 Functions are objects

 Everything is an object(Numbers are objects)

1 + 2 * 3 / x ====> (1).+(((2).*(3))./(x))

Scala Says
“If I were to pick a language to use today other than Java, it would be
Scala.”

- James Gosling, creator of Java

“Scala, it must be stated, is the current heir apparent to the Java
throne. No other language on the JVM seems as capable of being a

Why unify FP and OOP?
Both have complementary strengths for composition:

Functional programming: Object-oriented programming:

Makes it easy to build interesting Makes it easy to adapt and extend
things from simple parts, using complex systems, using
• higher-order functions, • subtyping and inheritance,
• algebraic types and • dynamic configurations,
pattern matching, • classes as partial abstractions.
• parametric polymorphism.

Modular programming

 Also known as top down design and stepwise refinement.
 A software design technique that increases the extent to which software
is composed of separate, interchangeable components called modules
by breaking down program functions into modules, each of which
accomplishes one function and contains everything necessary to
accomplish this.
 Conceptually, modules represent a separation of concerns, and improve
maintainability by enforcing logical boundaries between components.
 Modules are typically incorporated into the program through interfaces.

Why Need Modular Approach
Scala is a scalable language because we can use the same techniques to
construct small as well as large programs.

Programming in the large means organizing and assembling the smaller
pieces into larger programs, applications, or systems.

While the division of programs into packages is already quite helpful, it
is limited because it provides no way to abstract.

We cannot reconfigure a package two different ways within the same
program, and you cannot inherit between packages.

A package always includes one precise list of contents, and that list is
fixed until you change the code.

................................

Why we need Modular Approach.......
Firstly there should be a module construct that provides
a good separation of interface and implementation.

Secondly, there should be a way to replace one module with another that
has the same interface with out changing or recompiling the modules that
depend on the replaced one.

Lastly, there should be a way to wire modules together. This wiring task
can by thought of as configuring the system.

How To achieve Modular Approach
 How to use Scala’s object-oriented features to make a program more
modular

 How a simple singleton object can be used as a module

 How to use traits and classes as abstractions over modules. These
abstractions can be reconfigured into multiple modules, even multiple
times within the same program.

 How to use traits to divide a module across multiple files

To Build an enterprise web application you need the partition of the
software into layers, including

➔ a domain layer
➔ an application layer

In the domain layer, we define domain objects, which will capture business
concepts and rules and encapsulate state that will be persisted to an
external relational database.

In the application layer, we’ll provide an API organized in terms of the
services ,the application offers to clients (including the user interface layer).

The application layer will implement these services by coordinating tasks
and delegatingthe work to the objects of the domain layer.

Lets Start with an Example
An Enterprise web application that will allow users to manage recipes.

It will contains two entities that will be persisted in the database.

➔ Food
➔ Recipe

abstract class Food(val name: String) {
override def toString = name
}

class Recipe(val name: String,val ingredients: List[Food],val instructions:
String) {
override def toString = name
}

Here are some singleton instances of Food and Recipe classes, which can
be used when writing tests:

object Apple extends Food("Apple")
object Orange extends Food("Orange")
object Cream extends Food("Cream")
object Sugar extends Food("Sugar")

object FruitSalad extends Recipe("fruit salad",List(Apple, Orange, Cream,
Sugar),"Stir it all together.")

Scala uses objects for modules, so to modularize program we are making
two singleton objects to serve as the mock implementations of the
database and browser modules during testing.

object SimpleDatabase {
def allFoods = List(Apple, Orange, Cream, Sugar)
def foodNamed(name: String): Option[Food] =
allFoods.find(_.name == name)
def allRecipes: List[Recipe] = List(FruitSalad)
}
object SimpleBrowser {
def recipesUsing(food: Food) =
SimpleDatabase.allRecipes.filter(recipe =>
recipe.ingredients.contains(food))
}

You can use this database and browser as follows:

scala> val apple = SimpleDatabase.foodNamed("Apple").get
apple: Food = Apple

scala> SimpleBrowser.recipesUsing(apple)
res0: List[Recipe] = List(fruit salad)

To make things a little more interesting, suppose the database sorts foods
into categories. To implement this, you can add a FoodCategory class and a
list of all categories in the database.

eg. class FoodCategory(name: String, foods: List[Food])

object SimpleDatabase {


def foodNamed(name: String): Option[Food] =
allFoods.find(_.name == name)


case class FoodCategory(name: String, foods: List[Food])

private var categories = List(
FoodCategory("fruits", List(Apple, Orange)),
FoodCategory("misc", List(Cream, Sugar)))

def allCategories = categories
}
object SimpleBrowser {
SimpleDatabase.allRecipes.filter(recipe =>
def displayCategory(category: SimpleDatabase.FoodCategory) {
println(category)
}}

Abstraction
The SimpleBrowser module mentions the SimpleDatabase mod-
ule by name, you won’t be able to plug in a different implementation of the
database module without modifying and recompiling the browser module.
In addition, although there’s no hard link from the SimpleDatabase
moduleto the SimpleBrowser module,there’s no clear way to enable the
user interface layer, for example, to be configured to use different
implementations of the browser module.

abstract class Browser {
val database: Database

database.allRecipes.filter(recipe =>

def displayCategory(category: database.FoodCategory) {
println(category)
}
}

abstract class Database {
def allFoods: List[Food]
def allRecipes: List[Recipe]

def foodNamed(name: String) =
allFoods.find(f => f.name == name)
def allCategories: List[FoodCategory]
}

object SimpleDatabase extends Database {


private var categories = List(
FoodCategory("fruits", List(Apple, Orange)),
FoodCategory("misc", List(Cream, Sugar)))

def allCategories = categories
}

object SimpleBrowser extends Browser {
val database = SimpleDatabase
}

scala> val apple = SimpleDatabase.foodNamed("Apple").get
apple: Food = Apple

scala> SimpleBrowser.recipesUsing(apple)
res1: List[Recipe] = List(fruit salad)

Now we create a second mock database, and use the same
browser class with it

object StudentDatabase extends Database {
object FrozenFood extends Food(

Splitting modules into traits
Often a module is too large to fit comfortably into a single file. When that
happens, you can use traits to split a module into separate files. For
example ,suppose you wanted to move categorization code out of the
main Database file and into its own.

trait FoodCategories {
def allCategories: List[FoodCategory]
}

Now class Database can mix in the FoodCategories trait instead of defin-
ing FoodCategory and allCategories itself
abstract class Database extends FoodCategories {
def allFoods: List[Food]
def allRecipes: List[Recipe]
def foodNamed(name: String) =
allFoods.find(f => f.name == name)
}

Continuing in this way, you might try and divide SimpleDatabase into
two traits, one for foods and one for recipes.

object SimpleDatabase extends Database
with SimpleFoods with SimpleRecipes

The SimpleFoods trait could look as :

trait SimpleFoods {
object Pear extends Food("Pear")
def allFoods = List(Apple, Pear)
def allCategories = Nil
}

Runtime linking
One final feature of Scala modules is worth emphasizing: they can be linked
together at runtime, and you can decide which modules will link to which
depending on runtime computations.

object GotApples {
def main(args: Array[String]) {
val db: Database =
if(args(0) == "student")
StudentDatabase
else
SimpleDatabase
object browser extends Browser {
val database = db
}
val apple = SimpleDatabase.foodNamed("Apple").get
for(recipe <- browser.recipesUsing(apple))
println(recipe)
}
}

if you use the simple database, you will find a recipe for fruit salad. If
you use the student database, you will find no recipes at all using apples:

$ scala GotApples simple
fruit salad
$ scala GotApples student
$//No output

Tracking module instances
Despite using the same code, the different browser and database modules cre-
ated in the previous section really are separate modules. This means that each
module has its own contents, including any nested classes. FoodCategory
in SimpleDatabase, for example, is a different class from FoodCategory
in StudentDatabase!

scala> val category = StudentDatabase.allCategories.head
category: StudentDatabase.FoodCategory =
FoodCategory(edible,List(FrozenFood))
scala> SimpleBrowser.displayCategory(category)
<console>:12: error: type mismatch;
found
: StudentDatabase.FoodCategory
required: SimpleBrowser.database.FoodCategory
SimpleBrowser.displayCategory(category)
ˆ
If we want all FoodCategorys to be the same, we can accomplish
this by moving the definition of FoodCategory outside of any class or trait.

Modular programming Using Object in Scala

Modular programming Using Object in Scala

Recommended

More Related Content

What's hot (6)

Similar to Modular programming Using Object in Scala (20)

More from Knoldus Inc. (20)

Recently uploaded (20)

Modular programming Using Object in Scala