Credit to Li Haoyi

• Strongly inspired by his blog.
• Wicked smart.
  • Scala.js. Ammonite.
• Good parts are his.
• Anything stupid is mine.
• Originally he wrote about Scala.

Slide 3 of 85

Principle of Least Power

— Li Haoyi

Slide 5 of 85

Developers seek power & flexibility

• My design is so flexible!
• I'm not exactly sure how I'm going to do it, so…
• The requirements might change, so…

Slide 6 of 85

With Great Power

• If it can do anything it might do anything
• Bigger possible space to consider

Slide 7 of 85

Motivation

— Li Haoyi

Slide 8 of 85

Vocabulary check

Power

Slide 9 of 85

Vocabulary check

Power

Restriction

Slide 10 of 85

Vocabulary check

Power

Restriction

Possibility

Slide 11 of 85

Vocabulary check

Power

Restriction

Possibility

Constraint

Slide 12 of 85

Essay

Can we program stategically using the principle of least power in other languages, too?

Slide 16 of 85

What I'm not talking about

• Picking a language
• Picking a framework
• Picking a library
• Most of us don't get to pick those on a daily basis

Slide 17 of 85

switch (n) {
  case 1:
    cost += 25; break;
  case 2:
    cost += 25; goto case 1;
  case 3:
    cost += 50; goto case 1;
  default:
    Console.WriteLine("Invalid selection.");
    break;
}

From MSDN goto docs

Slide 19 of 85

Baz baz = null;
while (true) {
  // 20 lines calculating foo…
  if (!foo.isValid()) break;
  // 30 lines calculting bar…
  if (!bar.isValid()) break;
  // Another 30 lines calculating wah…
  if (!wah.isValid()) break;
  baz = new Baz(foo, bar, wah);
  break;
}
return baz;

Slide 23 of 85

Foo foo = calculateFoo();
Bar bar = calculateBar();
Wah wah = calculateWah();
if (foo.isValid() &&
    bar.isValid() &&
    wah.isValid()) {
  return new Baz(foo, bar, wah);
} else {
  return null;
}

Slide 24 of 85

var label;
if (havingGoodDay(bob)) label = "ok";
else label = "bitter";

Slide 28 of 85

var label;
if (havingGoodDay(bob)) label = "ok";
else label = "bitter";

// ----- or -----
const label =
  (havingGoodDay(bob)) ?
  "good" :
  "bitter";

Slide 29 of 85

From caniuse.com

Slide 30 of 85

From caniuse.com

Slide 31 of 85

function tellMeAboutYourFeels(bob) {
  var feels = "meh";
  if (goodDay(bob)) feels = "hawt";
  else if (badDay(bob)) feels = "bitter";
  return feels;
}

Slide 32 of 85

function tellMeAboutYourFeels(bob) {
  var feels = "meh";
  if (goodDay(bob)) feels = "hawt";
  else if (badDay(bob)) feels = "bitter";
  return feels;
}

// ----- or -----
function tellMeAboutYourFeels(bob) {
  if (goodDay(bob)) return "hawt";
  if (badDay(bob)) return "bitter";
  return "meh";
}

Slide 33 of 85

Prefer Immutabilty

• As far as possible
• Except if you really need the perf improvement
• Spoiler: Very little of your code does
• Limit the scope of mutabilty

Slide 34 of 85

List<String> names = myBffs();
// ----- or -----
const List<String> names = myBffs();
// ----- or -----
ImmutableList<String> names = myBffs();
// ----- or -----
const ImmutableList<String> names = myBffs();

Slide 36 of 85

List<String> names = myBffs();

const List<String> names = myBffs();
// ----- or -----
ImmutableList<String> names = myBffs();
// ----- or -----
const ImmutableList<String> names = myBffs();

Slide 37 of 85

class Node {
  String name()
}

Slide 40 of 85

class Node {
  String name()
}

class Graph {
  void addEdge(Node from, Node to)
  boolean hasCycle()
}

Slide 41 of 85

Looks Simple, but…

• Have to instantiate a Graph and Nodes
• Can only be used with these data types
• Node can't store anything but a string
• Limited interface for defining graph's connections

Slide 42 of 85

How can we make it better?

• Abstract Node type
  • User can define Node to hold whatever
• Abstract Graph type
  • User chooses how to define connections

Slide 43 of 85

Typical Approach

• Most of us have been taught OOP-y design
• Feels natural to have a class for each "thing"
• I don't think it's the best

Slide 45 of 85

class GraphUtil {
  static boolean hasCycle<N>(
    Set<N> nodes,
    Function<N, Set<N>> connectsTo(Node n)
  )
}

Slide 48 of 85

Haoyi's Ranking of Interfaces

1. Static method with standard types
2. Static method with custom types
3. Class which must be instantiated to be called
4. Abstract class which must be subclassed

Slide 49 of 85

Closure vs Class

Slide 51 of 85

Closure vs Class

• Both wrap (potentially mutable) state
• Both encapsulate data
• Both have method(s) which can be invoked

Slide 52 of 85

Closure vs Class

• Both wrap (potentially mutable) state
• Both encapsulate data
• Both have method(s) which can be invoked
• Closure "constructors" are plausible
• Closure only has one method
• You can fake more with stringy dispatch

Slide 53 of 85

Closure vs Class

• Both wrap (potentially mutable) state
• Both encapsulate data
• Both have method(s) which can be invoked
• Closure "constructors" are plausible
• Closure only has one method
• You can fake more with stringy dispatch
  • Please don't

Slide 54 of 85

Passing Classes to Functions

• Generally if a function needs a thing which can do stuff, we'll pass that object to it
• Often gives the function too much power
  • Can access unrelated data
  • Can access unneeded methods
  • Tight coupling produces brittleness
  • Can potentially mutate the object

Slide 55 of 85

Pass Closures, not Classes

• What if instead we pass more restrictive, less powerful thing?
• Provides a nice abstraction layer without explicitly defining interface
• Receiver can only take one action with closure
• Shared interface without inheritance

Slide 56 of 85

Architectural Hotspot Patterns

• Unstable interface
• Implicit cross-module dependency
• Unhealthy interface inheritance hierarchy
• Cross-module cycle
• Cross-package cycle

Adrian Colyer's blog

Slide 57 of 85

class Node {
  String name()
  Set<Node> connectsTo(Node n)
}
class Graph {
  static boolean hasCycle(Set<Node> nodes)
}
// ----- vs -----
class GraphUtil {
  static boolean hasCycle(Set<N> nodes,
    Function<N, Set<N>> connectsTo)
}
hasCycle(nodes, node::connectsTo)

Slide 58 of 85

The Better Option: Simpler Error Handling

• Option, Optional, or Maybe in most langauges
  • If not in standard then a third party library

Slide 66 of 85

The Better Option: Simpler Error Handling

• Option, Optional, or Maybe in most langauges
  • If not in standard then a third party library
• Allows you to indicate either a value or failure
• No confusion which is which
  • Is that -1 a value or a failure code?

Slide 67 of 85

The Better Option: Simpler Error Handling

• Option, Optional, or Maybe in most langauges
  • If not in standard then a third party library
• Allows you to indicate either a value or failure
• No confusion which is which
  • Is that -1 a value or a failure code?
• Short circuit evaluation bails out on error
• Pairs exquisitely with lambdas

Slide 68 of 85

for (
  x <- Some(5)
  y <- Some(7)
) yield x * y
// Results in Some(35)

Slide 70 of 85

for (
  x <- Some(5)
  y <- None
) yield x * y
// Results in None

Slide 71 of 85

Baz baz = null;
while (true) {
  // 20 lines calculating foo…
  if (!foo.isValid()) break;
  // 30 lines calculting bar…
  if (!var.isValid()) break;
  // Another 30 lines calculating wah…
  if (!wah.isValid()) break;
  baz = new Baz(foo, bar, wah);
  break;
}
return baz;

Slide 72 of 85

How can we make it better?

• Separate functions to make Foo, Bar, and Wah

Slide 73 of 85

How can we make it better?

• Separate functions to make Foo, Bar, and Wah
• Only create valid objects
• Use Option to indicate possibility of invalid

Slide 74 of 85

def makeFoo(): Option[Foo]
def makeBar(): Option[Bar]
def makeWah(): Option[Wah]
for (
  foo <- makeFoo()
  bar <- makeBar()
  wah <- makeWah()
) yield new Baz(foo, bar, wah)

Slide 75 of 85

Optional<Foo> makeFoo() { …}
Optional<Bar> makeBar() { … } 
Optional<Wah> makeWah() { … } 
return
  makeFoo().flatMap(foo ->
    makeBar().flatMap(bar ->
      makeWah().map(wah ->
        new Baz(foo, bar, wah);
  )));

Slide 76 of 85

The Better Option: Simpler Error Handling

• Avoids common pitfalls:
  • Not supposed to use throw for flow control
  • null is the Billion Dollar Mistake according to inventor
  • Don't have to remember to check error code

Slide 77 of 85

Limited Option

• We can't say what went wrong
• There are other types, like Either, to express more detailed failure

Slide 78 of 85

Summary

• Deliberate constraints simplify code use and maintenance

Slide 80 of 85

Summary

• Deliberate constraints simplify code use and maintenance
• Better predictability makes refactoring and testing easier

Slide 81 of 85

Summary

• Deliberate constraints simplify code use and maintenance
• Better predictability makes refactoring and testing easier
• More powerful solution is not necessarily better

Slide 82 of 85

Summary

• Deliberate constraints simplify code use and maintenance
• Better predictability makes refactoring and testing easier
• More powerful solution is not necessarily better
  • Mo' power, mo' problems!

Slide 83 of 85

How?

• Immutability
• Constrained Interfaces
• Lambdas to Restrict Coupling
• Option to Express Possible Failure

Slide 84 of 85