In this post I talked about the need to create simple and elegant solutions to software problems rather than over engineer. I used as example a property mechanism that I have been working on for my new product. Having now got this to a state where I believe it is both simple and elegant I thought I'd share the evolution of the Scala code as a way of exploring this topic in more detail.
The goal of this particular set of classes is to provide a mechanism whereby a (super)user can define definitions for the properties that can be set against an item. The user creating the item then fills in values for these properties. Both users will be utilising a web interface for defining and setting properties. In addition properties may be mandatory and optional and can support default values.
Please note that all the code below was developed iteratively using a Test-Drive Development (TDD) approach. I'm not going to show the tests here, so please be aware that every iteration through the model was first backed by a test to define the required behaviour.
So, after my initial attempt at a solution that became far too complex and over engineered I rolled back to the simplest thing that I could possibly write:
case class PropertyDefinition(name: String)
case class Property(name: String, value: String)
object Property {
def apply(definition: PropertyDefinition, value: String) = Property(definition.name, value)
}This simple starting point meets the minimum requirements of a definition of a property and then a property that maps a name to a string value. While this is indeed simple, it's too simple in that it doesn't meet all the requirements and it's also not particularly elegant in the way it restricts values to be strings.
The next step was to add support for mandatory/optional functionality. The property definition was easy to change:
case class PropertyDefinition(name: String, mandatory: Boolean = false)
However, the property concept is more challenging as it is now possible to have properties with no value associated. With the general Scala goal of avoiding using null to represent no value, I instead modified property to hold and Option[String] instead:
case class Property(name: String, value: Option[String])
object Property {
def apply(definition: PropertyDefinition, value: Option[String]) = value match {
case None if !definition.mandatory => new Property(definition.name, None)
case Some(_) => new Property(definition.name, value)
case _ => throw new IllegalArgumentException("Value must be supplied for property")
}
}This is still a pretty simple solution. However it's still missing the requirement for default value support and it now seems less elegant because instead of creating a property with
Property(nameDefinition, "value")
I have to use
Property(nameDefinition, Some("value"))Also, I'm still linked tightly to String value types. First I decided to deal with the default value requirement:
case class PropertyDefinition(name: String, mandatory: Boolean = false, defaultValue: Option[String] = None)
case class Property(name: String, value: Option[PropertyValue])
object Property {
def apply(definition: PropertyDefinition, value: Option[String]) = value match {
case None if definition.defaultValue != None => new Property(definition.name, definition.defaultValue)
case None if !definition.mandatory => new Property(definition.name, None)
case Some(_) => new Property(definition.name, value)
case _ => throw new IllegalArgumentException("Value must be supplied for property")
}
}I now have the simplest solution that meets all my requirements. Many developers would stop at this point, but I still feed uncomfortable that the code is not particularly elegant. I don't want to over engineer additional complexity but I'd like to have a cleaner interface to the classes that I have created so far and I'd also like to leave more scope for future changes where possible.
My first improvement was to pull out the tight coupling to a String and instead introduce a PropertyValue class as a wrapper around a string:
case class PropertyValue(content: String)
case class PropertyDefinition(name: String, mandatory: Boolean = false, defaultValue: Option[PropertyValue] = None)
case class Property(name: String, value: Option[PropertyValue])
object Property {
def apply(definition: PropertyDefinition, value: Option[PropertyValue]) = value match {
case None if definition.defaultValue != None => new Property(definition.name, definition.defaultValue)
case None if !definition.mandatory => new Property(definition.name, None)
case Some(_) => new Property(definition.name, value)
case _ => throw new IllegalArgumentException("Value must be supplied for property")
}
}Now my property code is not fixed to a string, although my initial implementation of property value is still string based. This has the benefit of keeping the initial version simple but providing scope for someone to refactor the implementation of property value in the future to support different types or other requirements.
So, one element of elegance of the code is improved. Unfortunately it comes at the expense of another. To create a property you now have to type:
Property(nameDefintion, Some(PropertyValue("value"))Yuk! I need a way to easily build an Option[PropertyValue] from a String in order to avoid all the boiler plate code. This is where Scala implicit conversions come to the rescue. I think their overuse can create code which can be very difficult to debug as you are never certain what implicit conversions are being applied. However in this case they are perfect for bringing the final level of elegance to the code:
object PropertyValue {
implicit def wrapString(content: String) = content match {
case "" => None
case _ => Some(new PropertyValue(content))
}
implicit def unwrapString(value: Option[PropertyValue]) = value match {
case Some(v) => v.content
case None => ""
}
}Given these implicit conversions I can now type:
val property = Property(nameDefinition, "value') val content: String = property.value
This ticks all my boxes for simplicity and elegance. The code is clean and simple; all the requirements are met. The interface to the classes is also clean and intuitive. However, the solution is also elegant in that it provides ways for future extension without adding excessive additional complexity. Future developers should be able to enhance this code to support more features (such as validation or type safe values) without having to rewrite it from scratch. Time to move on to the rest of my domain model...
