CODEWITHSUNDEEP
scalainheritanceconstructor
bbozo
bbozo

Reputation: 7301

Using overloaded constructors from the superclass

I'm writing a message parser. Suppose I have a superclass Message with two auxiliary constructors, one that accepts String raw messages and one that accepts a Map with datafields mapped out in key-value pairs.

class Message {
  def this(s: String)
  def this(m: Map[String, String])

  def toRaw = { ... } # call third party lib to return the generated msg
  def map # call third party lib to return the parsed message

  def something1 # something common for all messages which would be overriden in child classes
  def something2 # something common for all messages which would be overriden in child classes
  ...
}

There's good reason to do this as the library that does parsing/generating is kind of awkward and removing the complexity of interfacing with it into a separate class makes sense, the child class would look something like this:

class SomeMessage extends Message {
  def something1 # ...
  def something2 # ...
}

and the idea is to use the overloaded constructors in the child class, for example:

val msg = new SomeMessage(rawMessage) # or
val msg = new SomeMessage("fld1" -> ".....", "fld2" -> "....")

# and then be able to call
msg.something1
msg.something2 # ...

However, the way auxiliary constructors and inheritance seem to behave in Scala this pattern has proven to be pretty challenging, and the simplest solution I found so far is to create a method called constructMe, which does the work of the constructors in the above case:

val msg = new SomeMessage
msg.constructMe(rawMessage) # or
msg.constructMe("fld1" -> ".....", "fld2" -> "....")

which seems crazy to need a method called constructMe.

So, the question:

is there a way to structure the code so to simply use the overloaded constructors from the superclass? For example:

val msg = new SomeMessage(rawMessage) # or
val msg = new SomeMessage("fld1" -> ".....", "fld2" -> "....")

or am I simply approaching the problem the wrong way?

Upvotes: 0

Views: 374

Answers (1)

Ende Neu
Ende Neu

Reputation: 15783

Unless I'm missing something, you are calling the constructor like this:

val msg = new SomeMessage(rawMessage)

But the Message class doesn't not take a parameter, your class should be defined so:

class Message(val message: String) {
  def this(m: Map[String, String]) = this("some value from mapping")
}

Also note that the constructor in scala must call the primary constructor as first action, see this question for more info.

And then the class extending the Message class should be like this:

class SomeMessage(val someString: String) extends Message(someString) {
  def this(m: Map[String, String]) = this("this is a SomeMessage")
}

Note that the constructor needs a code block otherwise your code won't compile, you can't have a definition like def this(someString: String) without providing the implementation.

Edit:

To be honest I don't quite get why you want to use Maps in your architecture, your class main point it to contain a String, having to do with complex types in constructors can lead to problems. Let's say you have some class which can take a Map[String, String] as a constructor parameter, what will you do with it? As I said a constructor must call himself as first instruction, what you could is something like this:

class A(someString: String) = {
  def this(map: Map[String, String]) = this(map.toString)
}

And that's it, the restrictions in scala don't allow you to do anything more, you would want to do some validation, for example let's say you want to take always the second element in the map, this could throw exceptions since the user is not forced to provide a map with more than one value, he's not even forced to provide a filled map unless you start filling your class with requires.

In your case I probably would leave String as class parameter or maybe a List[String] where you can call mkString or toString.

Anyway if you are satisfied calling map.toString you have to give both constructor implementation to parent and child class, this is one of scala constructor restrictions (in Java you could approach the problem in a different way), I hope somebody will prove me wrong, but as far as I know there's no other way to do it.

As a side note, I personally find this kind of restriction to be correct (most of the time) since the force you to structure your code to be more rigorous and have a better architecture, think about the fact that allowing people to do whatever they want in a constructor (like in java) obfuscate their true purpose, that is return a new instance of a class.

Upvotes: 1

Related Questions