After a long time here is a post about Scala again. I played around with composition of objects an classes from traits.

This post is also a reaction to Thomas Biskups post Toying around ..., where he played around with Qi4j to perhaps find a better architecture for his rogue like rpg “JADE”. We sometimes talking about this and I once mentioned Scalas traits.

So here is a little example of object and class composition with traits in Scala from the domain of role play games. I implemented some simple traits which I used to compose a class and a (singelton) object.

package de.myndian.scala.rpg

// Something that has a “name”
trait Named
{
  def name : String
}

// Something that has “power”
trait Powered
{
  def power : Int
}

// A namend thing that can be hitted 
trait Hitable
{
  this: Named =>
  
  var hitpoints : Int
  
  def hit(points : Int)
  {
    hitpoints -= points
    print(name + “ was hitted with ” + points + “ points. ”) 
    if(hitpoints <= 0)
      println(name + " is dead.")
    else
      println(name + " has " + hitpoints + " hitpoints remaining.")
  }
}

// A named thing that can use its power to hit a hittable
trait Fighter
{
  this : Named with Powered =>
  
  val rnd = new Random(System.currentTimeMillis)
  
  def hit(target : Named with Hitable)
  {
    println(name + “ hits ” + target.name)
    target.hit(rnd.nextInt(power))
  }
}

class Door(val name : String, var hitpoints : Int) 
    extends Named
    with Hitable


// In this fight the dwarf “kills” a door 
object DemoFight
    extends Application
{
  var aDoor = new Door(“a door”, 10)

  object TheDwarf
      extends Named
      with Hitable
      with Fighter
      with Powered
  {
    val name = “the dwarf”
    val power = 10
    var hitpoints = 20
  }

  while(aDoor.hitpoints > 0)
    TheDwarf.hit(aDoor)
}

Some sample output:

the dwarf hits a door
a door was hitted with 3 points. a door has 7 hitpoints remaining.
the dwarf hits a door
a door was hitted with 7 points. a door is dead.

So Thomas, what about “SADE”? ;-)

Just a litte note aside: I know many people saying that object oriented software does not perform well. Mostly that is their pretext to do ancient procedural programming or - worse - to mix up both. But every informed developer knows that this is not true. The (performance, architectural, ...) problem of many oo-software is the mashup of procedural/relational on one side and object oriented on the other. A well-known advice is to build the simplest object oriented programm you could and to leave out optimization as far as you could. Optimize only if it is really, really necessary and only if you know very, very well where your performance lack resides.

This week I stumbled over such a situation. Last week - friday afternoon, of course - a customer called us that the result of the actual iteration does not work properly. A component which generates a network plan from a template and does some computations on that structure really killed the test system. A test on our development machine with their test data showed us that this process takes over three minutes of full workload of the hardware. And the plan had only 64 nodes.

So I took Nils over to a pair debugging session and we did some profiling. The bug was found quickly in the gap between some domain objects that evolved from a relational structure. To fix this we added a little cache to one class. The process took about one minute. Another cache and it performed in under one second! Without changing any other part of the system, because of the oo design.

We took this as a proof of the advices above.