Scala Patterns in the Linked Data Writer

Transcript

1. Common Scala Patterns
2. Common Scala Patterns IN THE Linked Data Writer
3. Common Scala Patterns IN THE Linked Data Writer Five Things I Spotted
4. 1 Rethrowing Exceptions catching(classOf[IllegalArgumentException]) .withApply(e => throw new Exception(e)) { // Do a potentially awful thing }
5. 1 Rethrowing Exceptions – Can be assigned to a val and re-used – We deal with fewer exception types – Slightly verbose – Not immediately obvious
6. 2 Custom Matchers val rdf = fixture("some_turtle.rdf") val value = "Newsnight" rdf must containTriple(None, "cwork:about", aidy)
7. 2 Custom Matchers – Hide away common complexity – Shorter, more readable tests – Easily re-used
8. 3 Enums & RDF Types object CreativeWorkType extends Enumeration { type CreativeWorkType = Value val Video, Gallery, BlogPost = Value } import CreativeWorkType.CreativeWorkType
9. 3 Enums & RDF Types – DRY-er than using strings – Helps with validation of types – Odd syntax for creation – Odd syntax for imports – Another mirror of the ontology
10. 4 Chunky Constructors case class CreativeWork( locator: Urn, title: String, modified: DateTime, format: Option[FormatType.FormatType] = None, created: Option[DateTime] = None, uri: Option[String] = None, primaryContentOf: List[PrimaryContentOf] = List(), about: List[String] = List(), mentions: List[String] = List(), type: CreativeWorkType = CreativeWorkType.CreativeWork, provenance: Option[CreativeWorkProvenance] = None, thumbnails: List[Thumbnail] = List(), audience: Option[AudienceType] = None)
11. 4 – Mostly hidden from 'general use' – ...at least, in our code – Not particularly nice to read – Forced by immutability – If it were mutable, we could use setters – No logical grouping of arguments – Alternative: builder pattern using .copy – But, the constructor uses named args anyway Chunky Constructors
12. 5 Validation The not-so-good way case class Dataset { def checkHasNoBlankNodes = { // do some stuff throw new InvalidDatasetException("Oh no!") } } put("/dataset") { // construct dataset dataset.checkHasNoBlankNodes }
13. 5 Validation The better way case class Dataset { def hasBlankNodes: Boolean = { // do some stuff } } put("/dataset") { // construct dataset require(dataset.hasBlankNodes == false) }
14. 5 – Clearer than calling methods that throw – Always throws IllegalArgumentException – Error always starts with requirement failed – Disclaimer: I ♥ require Validation
15. 5 – In my opinion... – Requirements that are always true should – happen inside the constructor – Other requirements (those which are only – true in some cases) should exist outside – the class. Validation
16. Discuss! @samstarling