Real-World Scala Design Patterns


Published on

Published in: Technology, Education
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Real-World Scala Design Patterns

  1. 1. Between ZERO &HERO Tips & Tricks for the Intermediate-Level Scala Developer Formerly known as “Real-World Scala Design Patterns" November 6th 2013 !@agemooij ✉
  2. 2. The Scala Skillz Gap Target Audience Zero ??? hero Absolute beginners Me You? Martin Odersky Miles Sabin Viktor Klang Daniel Spiewak Etc. > 50% ?
  3. 3. Agenda Tips Tricks { { Type Aliases Classtags Auto-lifted Partial Functions NoStackTrace ! Type Classes Context Bounds & implicitly @implicitnotfound low priority default implicits “Pattern” is such a big word
  4. 4. Tip: Type Aliases
  5. 5. Type Aliases Definition: Creating an alternate name for a type, and sometimes for its companion object You: “What would that be good for?”
  6. 6. Type Aliases Use Case: api usability When your API refers to external types... force your users (and yourself) to always have to import those types
  7. 7. Type Aliases Use Case: api usability By defining some type aliases in your base package... give your users (and yourself) these dependencies for free
  8. 8. Type Aliases Use Case: simplification Sometimes type signatures get in the way of understanding A few well-placed type aliases can hide that complexity And it saves a lot of typing too
  9. 9. Type Aliases Use Case: the standard library!
  10. 10. Mini Tip: ClassTag Reflection without the Performance Tax
  11. 11. ClassTag Explanation: Easy access to erased class and type information without the runtime performance overhead
  12. 12. Mini Tip: Auto-lifted Partial Functions You’re Probably Already Using This...
  13. 13. Auto-lifted Partial Functions Explanation: When reading method signatures such as these: You would think that you need to do this: But in fact Scala allows you to do this:
  14. 14. Auto-lifted Partial Functions Example: Don’t do this:
  15. 15. Auto-lifted Partial Functions Example: Do this: But watch out for MatchErrors if your partial function is not complete!
  16. 16. Mini Tip: NoStackTrace Exceptions without the Performance Tax
  17. 17. The NoStackTrace Trait Explanation: Remember this? Huh? For use in scala.util.Failure and other places that require Throwables without necessarily needing stack traces
  18. 18. ys ti c M Trick: Type Classes Demystified
  19. 19. Type Classes Definition: "A type of Adapter that uses Scala’s implicits to add some extra capabilities to an existing type without direct coupling" - Some guy on the internet “Sort of like @Autowire for types...” - Me
  20. 20. Type Classes Problem: How do I turn a T into a RiakValue? It would be nice if there were an easy way to constrain T to something that can be (de)serialized without forcing users to extend their domain classes from my traits
  21. 21. Type Classes Step 1: define some useful traits These are just regular Scala traits!
  22. 22. Type Classes Step 2: use them as implicit parameters Making the parameter implicit is (most of) the big trick that turns RiakSerializer into a type class
  23. 23. Mini Trick: Context Bounds & Implicitly Making Type Classes a little Prettier
  24. 24. Context Bounds & Implicitly Explanation: Implicit parameters that look like this: Can also be written like this: You can always get a reference to any implicit value or parameter using the implicitly[T] function
  25. 25. Context Bounds & Implicitly Explanation: You can add multiple context bounds to a type
  26. 26. Mini Trick: @ImplicitNotFound Think of Your Users!
  27. 27. @ImplicitNotFound Explanation: Remember this? When the compiler can’t find an implementation in implicit scope, it will complain in vague terms...
  28. 28. @ImplicitNotFound Explanation: The compiler errors can sometimes be a little confusing to unsuspecting developers...
  29. 29. @ImplicitNotFound Explanation: Ah, much better!
  30. 30. @ImplicitNotFound Explanation: Happier, less confused users
  31. 31. Final Trick: Low Priority Default Implicits Making Type Classes Actually Useful
  32. 32. Low Priority Default Implicits Why? You want to provide some default implementations of your type classes so your users don’t have to do all the work. The companion object for your type class is the perfect place for this, but....
  33. 33. Low Priority Default Implicits Problem: You don't want your users to run into these kinds of problems when they want to override your defaults
  34. 34. Low Priority Default Implicits Solution: Use the Scala rules for resolving implicits to your advantage by making sure your defaults have the lowest possible implicit resolution priority This is a very common trick in Scala libraries
  35. 35. Low Priority Default Implicits Even Predef.scala has them!
  36. 36. Type Classes Further Reading:
  37. 37. Low Priority Default Implicits Further Reading:
  38. 38. Thank You! QUESTIONS? !@agemooij ✉