Dynamic Language Practices

Developer Practices for
Dynamic Languages
“Unlearning Java/C#”
Dr Paul King, Director
ASERT, Australia
paulk@asert.com.au

Topics
Introduction
• Design patterns
• Refactoring
• Polyglot programming
• SOLID principles
© ASERT 2006-2010

• Other topics
• More Info

ESDC 2010 - 2

Introduction …
• Developer practices
– Well understood and documented for
traditional languages like Java, C++ and C#
– But dynamic languages like Groovy, Ruby,
Python, Boo, JavaScript and others,
change the ground rules
© ASERT 2006-2010

– Many of the rules and patterns we have
been taught must be adapted or adjusted;
some no longer apply at all

...Introduction...
• What does Immutability mean?
– When even constants can be changed
• What does encapsulation mean?
– When I can peek at internal state or
when using languages without state
• How can I devise tests
© ASERT 2006-2010

at development time?
– When my system can change in
unknown ways at runtime
• How can IDEs help me?
– If I no longer spoon feed static-type information to my
IDE, what level of support can it give me in terms of
code completion and error checking

… Introduction
• Traditional developer practice guidelines
– Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
(1995). Design Patterns: Elements of Reusable Object-
Oriented Software. Addison-Wesley.
– Martin Fowler (1999). Refactoring: Improving the Design of
Existing Code. Addison-Wesley.
– Joshua Bloch (2001). Effective Java Programming
© ASERT 2006-2010

Language Guide. Prentice Hall.
– Robert C Martin (2002), Agile Software Development,
Principles, Patterns, and Practices. Prentice Hall.
– Robert C Martin (2006), Agile Principles, Patterns, and
Practices in C#. Prentice Hall.
• In the dynamic language world, are the
guidelines in these books FACT or MYTH?
• But first let’s look at what we mean by
dynamic languages and dynamic typing

What do I mean by Dynamic Language?
• I prefer a flexible
definition
• One or more of:
– Dynamic typing
• Greater polymorphism
– Metaprogramming
© ASERT 2006-2010

• Allow language itself to be dynamically changed
• Allow hooks into object lifecycle and method calls
• Open classes/monkey patching
– Work with code as easily as data
• Closures
• Higher-order programming
– Escape hatches
• Hooks for polyglot programming

… Static vs Dynamic Typing …
• MYTH or TRUTH?
Static typing is just spoon feeding the
compiler/IDE. It represents the old-school
way of thinking and requires extra work
while providing no real value.
© ASERT 2006-2010

Static VS Dynamic

Static vs Dynamic Typing …
• Static: the type of each variable
(or expression) must be known
at compile time
© ASERT 2006-2010

dynamic advocates: like programming
wearing a straight-jacket?
Unnecessary complexity

…Static vs Dynamic Typing …
• Static Typing Pros
– Errors are often detected earlier and with better error
messages
– Code can sometimes be clearer – you don’t need to infer
the types to understand the code – especially when
revisiting the code later
© ASERT 2006-2010

– Safer because certain kinds of injection hacks don’t apply
– Code can be more declarative
– Better IDE support: refactoring, editing and other forms
of source processing support is often possible
– Better optimisations are often possible
– Often easier to understand a system from the outside
(“self-documenting” statically-typed APIs and interfaces)
– With generics support you can start to nail down even
complex cases

• Dynamic: type information is known only
at runtime
© ASERT 2006-2010

static advocates: like tightrope walking
with no net?

• Dynamic Typing Pros
– Speed development through duck-typing
and less boiler-plate code
– Clearer more concise code is easier to
read and maintain
– Allow more expressiveness through DSLs
© ASERT 2006-2010

– You should have comprehensive tests anyway, why not
cover off types as part of those tests
– Enforced healthy practices:
• Static language developers may get a false sense of
security and not design/test for runtime issues
• Less likely to neglect good documentation and/or good
coding conventions on the grounds that your static
types make everything “inherently” clear

• Strong vs weak typing
– Strong: List<Integer> myList
– Weak: Object myList
• Type safety
– How is this provided if at all?
© ASERT 2006-2010

• Type inference
– Is this supported?

…Static and Dynamic Typing…
© ASERT 2006-2010

Source: http://www.slideshare.net/pcalcado/one-or-two-things-you-may-not-know-about-typesystems

Correctness?
© ASERT 2006-2010


Typing Approaches…

interface Duck {
def waddle()
def quack()
}

class DuckImpl implements Duck {
© ASERT 2006-2010

def waddle() { println "waddle" }
def quack() { println "quack" }
}

class Goose {
def waddle() { println "Goose waddle" }
def quack() { println "Goose quack" }
}

…Typing Approaches…
• Inheritance hierarchies
– Very clear intent but use sparingly
• Interface-oriented design
– Use if it adds clarity & your language supports it
– If you do use it, stick to fine-grained interfaces
• Dynamic interface-oriented design
© ASERT 2006-2010

Source: Rick DeNatale
– If your language doesn’t support it natively you © David Friel

can use a guard: is_a?, kind_of?, instanceof
• Chicken typing
– Use a guard: responds_to?, respondsTo
• Duck typing
– Use when flexibility is important but have appropriate tests in
place; e.g. you don’t want to violate the Liskov Substitution
Principal[15] by not considering a refused bequest[13].
• AKA roll your own type safety

…Typing Approaches
• Implicit vs Explicit interfaces
– Inheritance too restrictive?
– Duck-typing too flexible? Menu
set_sides()

Shape <<interface>> <<interface>> Rectangle
draw() Shape RegularPolygon draw()
draw() set_side() set_sides()
© ASERT 2006-2010

Rectangle Square
draw() draw()
set_sides() Rectangle Square EquilateralTriangle set_side()
draw() draw() draw()
set_sides() set_side() set_side()

Square Pistol
draw() draw()
set_sides()
I tend to use Explicit types
for major boundaries and EquilateralTriangle
implicit types internally. draw()
set_side()

Adapted from Interface-Oriented Design [2]

• MYTH
Removing static typing always leads to
more concise and readable code.
© ASERT 2006-2010

X incorrect

• An example interface Reversible {
def reverse()
}

class ReversibleString implements Reversible {
def reverse() { /* */ }
}

class ReversibleArray implements Reversible {
}
© ASERT 2006-2010

Reversible[] things = [
new ReversibleString(), new ReversibleArray()
]

for (i in 0..<things.size()) {
things[i].reverse()
}

def things = ["abc", [1, 2 ,3]]
def expected = ["cba", [3, 2, 1]]
assert things*.reverse() == expected

… Static vs Dynamic Typing ...
interface Reversible {
With dynamically def reverse()
typed languages, }
there is no need to class ReversibleString implements Reversible {
explicitly declare the def reverse() { /* */ }
}
types of variables or
the “protocols” class ReversibleArray implements Reversible {
observed by our }
© ASERT 2006-2010

objects:
 Less code Reversible[] things = [
new ReversibleString(), new ReversibleArray()
 Less declarative ]
 Less IDE support for (i in 0..<things.size()) {
 More testing things[i].reverse()
 Less Robust? }

def things = ["abc", [1, 2 ,3]]
def expected = ["cba", [3, 2, 1]]
assert things*.reverse() == expected

• MYTH
Dynamic typing means the IDE can’t
provide support for completion and early
syntax error checks.
© ASERT 2006-2010

X incorrect

• Consider Groovy in Intellij

• And Eclipse
© ASERT 2006-2010

Eclipse example: http://contraptionsforprogramming.blogspot.com/

Typing approaches and IDEs…
• Class A has a bit of duplication

class A {
def helper
def make() {
helper.invoke('create')
}
def get() {
© ASERT 2006-2010

helper.invoke('read')
}
def change() {
helper.invoke('update')
}
def remove() {
helper.invoke('delete')
}
}

… Typing approaches and IDEs …
• No problems, we can refactor out the dup
class B {
def helper
def make() {
invoke('create')
}
def get() {
© ASERT 2006-2010

invoke('read')
}
def change() {
invoke('update')
}
def remove() {
invoke('delete')
}
private invoke(cmd) {
helper.invoke(cmd)
}
}

• But we can do more using a dynamic
language by leveraging metaprogramming
class C {
def helper
def commands = [
make: 'create',
© ASERT 2006-2010

get: 'read',
change: 'update',
remove: 'delete'
]
def invokeMethod(String name, ignoredArgs) {
helper.invoke(commands[name])
}
}

• Which is a whole lot nicer?
• At the expense of IDE completion? … ...


class Dumper {
def name
def invokeMethod(String methodName, args) {
println "$name: called $methodName with $args"
}
}
© ASERT 2006-2010

for (x in [A, B, C]) {
def o = x.newInstance()
o.helper = new Dumper(name: "$x.name's helper")
o.make()
o.get()
o.change()
o.remove()
}

… Typing approaches and IDEs
• … At the expense of IDE completion?
© ASERT 2006-2010

But remember:
“clearly express intent”

© ASERT 2006-2010

• MYTH
Static typing means runtime errors are a
thing of the past.

X incorrect
Source: http://www.slideshare.net/pcalcado/one-or-two-things-you-may-not-know-about-typesystems (phillip calçado)

• Consider Lift (based on Scala)
<lift:surround with="default" at="content">
<h2>Welcome to your project!</h2>
<p><lift:hellWorld.howdy /></p>
</lift:surround> Result: No error but
empty home page
© ASERT 2006-2010

<lift:surrond with="default" at="content">
<h2>Welcome to your project!</h2>
<p><lift:hellWorld.howdy /></p>
</lift:surround>

Source: http://zef.me/2371/when-scala-dsls-fail

Static and Dynamic Strong Typing
© ASERT 2006-2010


Static vs Dynamic Typing

Static Dynamic

Syntax bugs
Optimisation
© ASERT 2006-2010

Arithmetic bugs
Logic bugs
approx same approx same
Resource bugs
Concurrency bugs
Power
Flexibility

Static vs Dynamic Typing Verdict
• MYTH or TRUTH?

Static typing is just spoon feeding the
compiler. It represents the old-school way
of thinking and requires extra work while
providing no real value.
© ASERT 2006-2010

...but not a total lie either...

...dynamic languages certainly assist
with removing duplication, clutter and
boilerplate code...

An open debate
© ASERT 2006-2010


Topics
• Introduction
Design patterns
• Refactoring
© ASERT 2006-2010

• Other topics
• More Info

Language features instead of Patterns
• So called "Design Patterns" are merely
hacks to overcome the limitations of your
language
– You call that a
language?
© ASERT 2006-2010

– This is a language

• "Design Patterns" are really anti-patterns
you must sometimes put up with because
your language is so archaic!
• In my superior language, that would be
built-in, simply a library, so easy, ...

Adapter Pattern…
class RoundPeg {
def radius
String toString() { "RoundPeg with radius $radius" }
}

class RoundHole {
def radius
def pegFits(peg) { peg.radius <= radius }
String toString() { "RoundHole with radius $radius" }
}
© ASERT 2006-2010

def pretty(hole, peg) {
if (hole.pegFits(peg)) println "$peg fits in $hole"
else println "$peg does not fit in $hole"
}

def hole = new RoundHole(radius:4.0)
(3..6).each { w -> pretty(hole, new RoundPeg(radius:w)) }

RoundPeg with radius 3 fits in RoundHole with radius 4.0
RoundPeg with radius 4 fits in RoundHole with radius 4.0
RoundPeg with radius 5 does not fit in RoundHole with radius 4.0
RoundPeg with radius 6 does not fit in RoundHole with radius 4.0

…Adapter Pattern…
class SquarePeg {
def width
String toString() { "SquarePeg with width $width" }
}

class SquarePegAdapter {
def peg
def getRadius() { Math.sqrt(((peg.width/2) ** 2)*2) }
String toString() {
"SquarePegAdapter with width $peg.width (and notional radius $radius)"
© ASERT 2006-2010

}
}

def hole = new RoundHole(radius:4.0)

(4..7).each { w ->
pretty(hole, new SquarePegAdapter(peg: new SquarePeg(width: w))) }

SquarePegAdapter with width 4 (and notional radius 2.8284271247461903)
fits in RoundHole with radius 4.0
fits in RoundHole with radius 4.0
does not fit in RoundHole with radius 4.0
does not fit in RoundHole with radius 4.0

…Adapter Pattern

SquarePeg.metaClass.getRadius =
{ Math.sqrt(((delegate.width/2)**2)*2) }

(4..7).each { w -> pretty(hole, new SquarePeg(width:w)) }
© ASERT 2006-2010

Adapter Pattern
Do I create a whole new class
or just add the method I need
on the fly?
Consider the Pros and Cons!

SquarePeg with width 4 fits in RoundHole with radius 4.0
SquarePeg with width 5 fits in RoundHole with radius 4.0
SquarePeg with width 6 does not fit in RoundHole with radius 4.0
SquarePeg with width 7 does not fit in RoundHole with radius 4.0

Further reading: James Lyndsay, Agile is Groovy, Testing is Square

Adapter Pattern Verdict
• Dynamic languages can make it easier to
apply the adapter pattern to the extent that
its use may not even be apparent:
– Express intent more clearly and improves readability
– Aids refactoring
–
© ASERT 2006-2010

Can help with test creation
– Avoids class proliferation
• At the expense of class pollution?
– But you still need testing

Immutable Pattern...
• Java Immutable Class boilerplate
– As per Joshua Bloch // ...
@Override
Effective Java public boolean equals(Object obj) {
if (this == obj)
public final class Punter { return true;
private final String first; if (obj == null)
private final String last; return false;
if (getClass() != obj.getClass())
public String getFirst() { return false;
return first; Punter other = (Punter) obj;
} if (first == null) {
© ASERT 2006-2010

if (other.first != null)
public String getLast() { return false;
return last; } else if (!first.equals(other.first))
} return false;
if (last == null) {
@Override if (other.last != null)
public int hashCode() { return false;
final int prime = 31; } else if (!last.equals(other.last))
int result = 1; return false;
result = prime * result + ((first == null) return true;
? 0 : first.hashCode()); }
result = prime * result + ((last == null)
? 0 : last.hashCode()); @Override
return result; public String toString() {
} return "Punter(first:" + first
+ ", last:" + last + ")";
public Punter(String first, String last) { }
this.first = first;
this.last = last; }
}
// ...
QCON 2010 - 41

...Immutable Pattern

@Immutable class Punter {
String first, last
© ASERT 2006-2010

}

QCON 2010 - 42

Visitor Pattern
abstract class Shape {}

class Rectangle extends Shape {
def x, y, width, height Visitor Pattern abstract class Shape {
Rectangle(x, y, width, height) {
def accept(Closure yield) { yield(this) }
} without closures
this.x = x; this.y = y; this.width = width; this.height = height

}
def union(rect) {
if (!rect) return this
def minx = [rect.x, x].min()
with closures class Rectangle extends Shape {
def maxx = [rect.x + width, x + width].max()
def miny = [rect.y, y].min()
def maxy = [rect.y + height, y + height].max() def x, y, w, h
new Rectangle(minx, miny, maxx - minx, maxy - miny)
} def bounds() { this }
def accept(visitor) { def union(rect) {
visitor.visit_rectangle(this)
} if (!rect) return this
}
def minx = [rect.x, x].min()
class Line extends Shape {
def x1, y1, x2, y2 def maxx = [rect.x + w, x + w].max()
Line(x1, y1, x2, y2) { def miny = [rect.y, y].min()
this.x1 = x1; this.y1 = y1; this.x2 = x2; this.y2 = y2
} def maxy = [rect.y + h, y + h].max()
def accept(visitor) { new Rectangle(x:minx, y:miny, w:maxx - minx, h:maxy - miny)
visitor.visit_line(this)
} }
© ASERT 2006-2010

}
}
class Group extends Shape {
def shapes = []

def add(shape) { shapes += shape } class Line extends Shape {
def remove(shape) { shapes -= shape } def x1, y1, x2, y2
def accept(visitor) { def bounds() {
visitor.visit_group(this)
} new Rectangle(x:x1, y:y1, w:x2-y1, h:x2-y2)
}
}
class BoundingRectangleVisitor {
def bounds }
def visit_rectangle(rectangle) {
if (bounds)
bounds = bounds.union(rectangle) class Group {
else
bounds = rectangle def shapes = []
}
def leftShift(shape) { shapes += shape }
def visit_line(line) {
def line_bounds = new Rectangle(line.x1, line.y1, line.x2 - line.y1, line.x2 - line.y2) def accept(Closure yield) { shapes.each{it.accept(yield)} }
if (bounds)
bounds = bounds.union(line_bounds) }
else
bounds = line_bounds
}
def group = new Group()
def visit_group(group) {
group.shapes.each {shape -> shape.accept(this) } group << new Rectangle(x:100, y:40, w:10, h:5)
}
} group << new Rectangle(x:100, y:70, w:10, h:5)
def group = new Group() group << new Line(x1:90, y1:30, x2:60, y2:5)
group.add(new Rectangle(100, 40, 10, 5))
group.add(new Rectangle(100, 70, 10, 5)) def bounds
group.add(new Line(90, 30, 60, 5))
def visitor = new BoundingRectangleVisitor() group.accept{ bounds = it.bounds().union(bounds) }
group.accept(visitor)
bounding_box = visitor.bounds println bounds.dump()
println bounding_box.dump()

See also Ruby Visitor

Visitor Pattern Verdict
apply the visitor pattern to the extent that
its use may not even be apparent:
–
© ASERT 2006-2010

Avoids class proliferation

Strategy Pattern
© ASERT 2006-2010

Source: http://nealford.com/

Language features instead of Patterns…
interface Calc {
def execute(n, m) Strategy Pattern
}
with interfaces
class CalcByMult implements Calc { with closures
def execute(n, m) { n * m }
}
def multiplicationStrategies = [
class CalcByManyAdds implements Calc {
def execute(n, m) {
{ n, m -> n * m },
def result = 0 { n, m ->
n.times { def total = 0; n.times{ total += m }; total },
result += m { n, m -> ([m] * n).sum() }
} ]
© ASERT 2006-2010

return result
}
}
def sampleData = [
[3, 4, 12],
def sampleData = [ [5, -5, -25]
[3, 4, 12], ]
[5, -5, -25]
] sampleData.each{ data ->
Calc[] multiplicationStrategies = [
multiplicationStrategies.each{ calc ->
new CalcByMult(), assert data[2] == calc(data[0], data[1])
new CalcByManyAdds() }
] }

sampleData.each {data ->
multiplicationStrategies.each {calc ->
assert data[2] == calc.execute(data[0], data[1])
}
}

Strategy Pattern Verdict
apply the strategy pattern to the extent
that its use may not even be apparent:
– Closures open up whole new possibilities for solving
problems
© ASERT 2006-2010

– Can help with test creation
– Avoids class proliferation

Builder Pattern: MarkupBuilder…
• Builder pattern from the GoF at the syntax-level
• Represents easily any nested tree-structured data

import groovy.xml.* • Create new builder
def b = new MarkupBuilder()
b.html { • Call pretended methods
© ASERT 2006-2010

head { title 'Hello' } (html, head, ...)
body { • Arguments are Closures
ul {
for (count in 1..5) { • Builder code looks very
li "world $count" declarative but is ordinary
} } } } Groovy program code and
can contain any kind of
NodeBuilder, DomBuilder, logic
SwingBuilder, AntBuilder, …

...Builder Pattern: MarkupBuilder

<html>
<head>
import groovy.xml.* <title>Hello</title>
def b = new MarkupBuilder() </head>
b.html { <body>
© ASERT 2006-2010

head { title 'Hello' } <ul>
body { <li>world 1</li>
ul { <li>world 2</li>
for (count in 1..5) { <li>world 3</li>
li "world $count" <li>world 4</li>
} } } } <li>world 5</li>
</ul>
</body>
</html>

Builder Pattern: SwingBuilder
import java.awt.FlowLayout
builder = new groovy.swing.SwingBuilder()
langs = ["Groovy", "Ruby", "Python", "Pnuts"]

gui = builder.frame(size: [290, 100],
title: 'Swinging with Groovy!’) {
panel(layout: new FlowLayout()) {
panel(layout: new FlowLayout()) {
for (lang in langs) {
© ASERT 2006-2010

checkBox(text: lang)
}
}
button(text: 'Groovy Button', actionPerformed: {
builder.optionPane(message: 'Indubitably Groovy!').
createDialog(null, 'Zen Message').show()
})
button(text: 'Groovy Quit',
actionPerformed: {System.exit(0)})
}
}
gui.show()
Source: http://www.ibm.com/developerworks/java/library/j-pg04125/

Builder Pattern: JavaFX Script

Frame {
title: "Hello World F3"
width: 200
content: Label {
text: "Hello World"
© ASERT 2006-2010

}
visible: true
}

Builder Pattern: Cheri::Swing

# requires JRuby
require 'rubygems'
© ASERT 2006-2010

require 'cheri/swing'
include Cheri::Swing

@frame = swing.frame('Hello') {
size 500,200
flow_layout
on_window_closing {|event| @frame.dispose}
button('Hit me') {
on_click { puts 'button clicked' }
}
}
@frame.show

Builder Pattern: AntBuilder
def ant = new AntBuilder()

ant.echo("hello") // let's just call one task

// create a block of Ant using the builder pattern
ant.sequential {
myDir = "target/test/"
mkdir(dir: myDir)
© ASERT 2006-2010

copy(todir: myDir) {
fileset(dir: "src/test") {
include(name: "**/*.groovy")
}
}
echo("done")
}

// now let's do some normal Groovy again
file = new File("target/test/AntTest.groovy")
assert file.exists()

Builder Pattern Verdict
• The builder pattern in combination with
dynamic languages helps me:
– Can help with test creation
– Tests are still important
© ASERT 2006-2010

Delegation Pattern ...
• Traditional approach to creating a class that is an
extension of another class is to use inheritance
– Clearest intent & simplest, clearest code for simple cases

class Person {
private name, age
Person(name, age) {
this.name = name
this.age = age
© ASERT 2006-2010

}
def haveBirthday() { age++ }
String toString() { "$name is $age years old" }
}

class StaffMemberUsingInheritance extends Person {
private salary
StaffMemberUsingInheritance(name, age, salary) {
super(name, age)
this.salary = salary
}
String toString() {
super.toString() + " and has a salary of $salary"
}
}

… Delegation Pattern ...
• Most common alternative is to use delegation
– Intention less clear (can be helped with interfaces)
– Overcomes multiple inheritance issues & inheritance abuse

class StaffMemberUsingDelegation {
private delegate
private salary
StaffMemberUsingDelegation(name, age, salary) {
© ASERT 2006-2010

delegate = new Person(name, age)
}
def haveBirthday() {
delegate.haveBirthday()
}
String toString() {
delegate.toString() + " and has a salary of $salary"
}
}

… Delegation Pattern …
• Downside of delegation is maintenance issues
– Refactoring overhead if we change the base class
– Meta-programming allows us to achieve inheritance
like behavior by intercepting missing method calls
(invokeMethod or method_missing)
– You could take this further with Groovy using named
© ASERT 2006-2010

parameters rather than the traditional positional
parameters shown here (future versions of Ruby may
have this too)

… Delegation Pattern …
class StaffMemberUsingMOP {
private delegate
private salary
StaffMemberUsingMOP(name, age, salary) {
delegate = new Person(name, age)
}
def invokeMethod(String name, args) {
delegate.invokeMethod name, args
}
© ASERT 2006-2010

String toString() {
delegate.toString() + " and has a salary of $salary"
}
}

def p1 = new StaffMemberUsingInheritance("Tom", 20, 1000)
def p2 = new StaffMemberUsingDelegation("Dick", 25, 1100)
def p3 = new StaffMemberUsingMOP("Harry", 30, 1200)
p1.haveBirthday()
println p1
p2.haveBirthday() Tom is 21 years old and has a salary of 1000
println p2 Dick is 26 years old and has a salary of 1100
p3.haveBirthday()
Harry is 31 years old and has a salary of 1200
println p3

… Delegation Pattern
• Going Further
–The example shown (on the previous slide) codes the
delegate directly but both Groovy and Ruby let you
encapsulate the delegation pattern as a library:
• Groovy: Delegator, Injecto; Ruby: forwardable, delegate
–But only if I don’t want to add logic as I delegate
• E.g. If I wanted to make haveBirthday() increment salary
© ASERT 2006-2010

class StaffMemberUsingLibrary {
private salary
private person
StaffMemberUsingLibrary(name, age, salary) {
person = new Person(name, age)
def delegator = new Delegator(StaffMemberUsingLibrary, person)
delegator.delegate haveBirthday
}
String toString() {
person.toString() + " and has a salary of $salary"
}
}

Better Design Patterns: Delegate…
public Date getWhen() {
import java.util.Date;
return when;
}
public class Event {
private String title;
public void setWhen(Date when) {
private String url;
this.when = when;
private Date when;
}
public String getUrl() {
public boolean before(Date other) {
return url;
return when.before(other);
}
© ASERT 2006-2010

}
public void setUrl(String url) {
public void setTime(long time) {
this.url = url;
when.setTime(time);
}
}
public String getTitle() {
public long getTime() {
return title;
return when.getTime();
}
}
public void setTitle(String title) {
public boolean after(Date other) {
this.title = title;
return when.after(other);
}
}
// ...
// ...
QCON 2010 - 60

…Better Design Patterns: Delegate…
public Date getWhen() {
import java.util.Date;
return when;
boilerplate }
public class Event {
private String title;
public void setWhen(Date when) {
private String url;
this.when = when;
private Date when;
}
public String getUrl() {
public boolean before(Date other) {
return url;
return when.before(other);
}
© ASERT 2006-2010

}
public void setUrl(String url) {
public void setTime(long time) {
this.url = url;
when.setTime(time);
}
}
public String getTitle() {
public long getTime() {
return title;
return when.getTime();
}
}
public void setTitle(String title) {
public boolean after(Date other) {
this.title = title;
return when.after(other);
}
}
// ...
// ...
QCON 2010 - 61

…Better Design Patterns: Delegate

class Event {
String title, url
@Delegate Date when
}
© ASERT 2006-2010

def gr8conf = new Event(title: "GR8 Conference",
url: "http://www.gr8conf.org",
when: Date.parse("yyyy/MM/dd", "2009/05/18"))

def javaOne = new Event(title: "JavaOne",
url: "http://java.sun.com/javaone/",
when: Date.parse("yyyy/MM/dd", "2009/06/02"))

assert gr8conf.before(javaOne.when)

QCON 2010 - 62

Delegation Pattern Verdict
• The delegation pattern can be expressed
more succinctly with dynamic languages:
– But don’t forget the testing implications
© ASERT 2006-2010

Singleton Pattern…
• Pattern Intent • Static language discussion
points
– Ensure that only one – Need exactly one instance of a class
instance of a class is and a well-known controlled access
created point
• Allows for lazy creation of instance
– Provide a global point of – More flexible than static class
access to the object variables and methods alone
• Permits refinement of operations and
– Allow multiple instances representation through subclassing
© ASERT 2006-2010

in the future without – Reduces name space clutter
affecting a singleton • Compared to using static approach
– Multi-threading implications
class's clients
– Serializable implications
• need to have readResolve() method to
avoid spurious copies
– Garbage collection implications
• May need "sticky" static self-reference
– Need to be careful subclassing
• Parent may already create instance or be
final or constructor may be hidden

…Singleton Pattern…
• The details quickly get messy …
public final class Singleton {
private static final class SingletonHolder {
static final Singleton singleton = new Singleton();
}
private Singleton() {}
public static Singleton getInstance() {
return SingletonHolder.singleton;
© ASERT 2006-2010

}
}

public class Singleton implements java.io.Serializable {
public static Singleton INSTANCE = new Singleton();
protected Singleton() {
// Exists only to thwart instantiation.
}
private Object readResolve() {
return INSTANCE;
}
}

• State of the art approach in Java?
– Use an IoC framework, e.g. Spring or Guice
import com.google.inject.*

@ImplementedBy(CalculatorImpl)
interface Calculator {
def add(a, b)
}
© ASERT 2006-2010

@Singleton
class CalculatorImpl implements Calculator {
private total = 0
def add(a, b) { total++; a + b }
def getTotalCalculations() { 'Total Calculations: ' + total }
String toString() { 'Calc: ' + hashCode()}
}

class Client {
@Inject Calculator calc
// ...
}

def injector = Guice.createInjector()

• But it is easy using meta-programming
– Old style

class Calculator {
private total = 0
© ASERT 2006-2010

def getTotalCalculations() { 'Total Calculations: ' + total }
String toString() { 'Calc: ' + hashCode()}
}

class CalculatorMetaClass extends MetaClassImpl {
private final static INSTANCE = new Calculator()
CalculatorMetaClass() { super(Calculator) }
def invokeConstructor(Object[] arguments) { return INSTANCE }
}

def registry = GroovySystem.metaClassRegistry
registry.setMetaClass(Calculator, new CalculatorMetaClass())

• But it is easy using meta-programming
class Calculator {
def total = 0
}

def INSTANCE = new Calculator()
© ASERT 2006-2010

Calculator.metaClass.constructor = { -> INSTANCE }

def c1 = new Calculator()
def c2 = new Calculator()

assert c1.add(1, 2) == 3
assert c2.add(3, 4) == 7

assert c1.is(c2)
assert [c1, c2].total == [2, 2]

• Or annotations

@Singleton(lazy=true)
class X {
def getHello () {
"Hello, World!"
© ASERT 2006-2010

}
}

println X.instance.hello

• And again with Ruby
class Aardvark class Aardvark
private_class_method :new private_class_method :new
@@instance = new def Aardvark.instance
def Aardvark.instance @@instance = new if not @@instance
@@instance @@instance
end end
end end
© ASERT 2006-2010

module ThreadSafeSingleton
def self.append_features(clazz)
require 'thread'
clazz.module_eval {
private_class_method :new
@instance_mutex = Mutex.new
def self.instance
@instance_mutex.synchronize {
@instance = new if not (@instance)
@instance
}
end
}
end
end Source: http://c2.com/cgi/wiki?RubySingleton

…Singleton Pattern
• Or for Python
– Classic class version (pre 2.2)
class Borg:
_shared_state = {}
def __init__(self):
self.__dict__ = self._shared_state

– Non-classic class version
© ASERT 2006-2010

class Singleton (object):
instance = None
def __new__(cls, *args, **kargs):
if cls.instance is None:
cls.instance = object.__new__(cls, *args, **kargs)
return cls.instance

# Usage
mySingleton1 = Singleton()
mySingleton2 = Singleton()
assert mySingleton1 is mySingleton2

Source: [10] and wikipedia

Singleton Pattern Verdict
• The singleton pattern can be expressed in
better ways with dynamic languages:
– But don’t forgot testing implications
© ASERT 2006-2010

Pattern Summary
• Patterns can be replaced by language
features and libraries
© ASERT 2006-2010

• So patterns aren’t important any more!

...

Topics
• Introduction
• Design patterns
Refactoring
© ASERT 2006-2010

• Other topics
• More Info

Refactoring Refactoring
• Out with the Old
– Some refactorings no longer make sense
• In with the New
– There are some new refactorings
• Times … they are a changin’
© ASERT 2006-2010

– Some refactorings are done differently

Encapsulate Downcast Refactoring
• Description
– Context: A method returns an object that
needs to be downcasted by its callers
– Solution: Move the downcast to within the method
• Is there a point in a dynamic language?
– Maybe but not usually
© ASERT 2006-2010

// Before refactoring
Object lastReading() {
return readings.lastElement()
}

// After refactoring
Reading lastReading() {
return (Reading) readings.lastElement()
}

Introduce Generics Refactoring
• Description
– Context: Casting is a runtime hack that allows
JVM to clean up a mess caused by a compiler
that couldn’t infer intent
– Solution: Use Generics to reveal intent to compiler

• Is there a point in a dynamic language?
© ASERT 2006-2010

– Maybe but not usually
// Traditional Java style
List myIntList = new LinkedList()
myIntList.add(new Integer(0))
Integer result = (Integer) myIntList.iterator().next()

// Java generified style
List<Integer> myIntList2 = new LinkedList<Integer>()
myIntList2.add(new Integer(0))
Integer result2 = myIntList2.iterator().next()

// Groovier style
def myIntList3 = [0]
def result3 = myIntList3.iterator().next()

Enabling a functional style …
• Consider the Maximum Segment Sum
(MSS) problem
– Take a list of integers; the MSS is the maximum of the sums of
any number of adjacent integers

• Imperative solution:
def numbers = [31,-41,59,26,-53,58,97,-93,-23,84]
© ASERT 2006-2010

def size = numbers.size()
def max = null
(0..<size).each { from ->
(from..<size).each { to ->
def sum = numbers[from..to].sum()
if (max == null || sum > max) max = sum
}
}

println "Maximum Segment Sum of $numbers is $max"

… Enabling a functional style …
• A first attempt at a more functional style:

def numbers = [31,-41,59,26,-53,58,97,-93,-23,84]
© ASERT 2006-2010

def size = numbers.size()
def max = [0..<size, 0..<size].combinations().collect{
numbers[it[0]..it[1]].sum()
}.max()

println "Maximum Segment Sum of $numbers is $max"

… Enabling a functional style …
• An even more functional style
– A known solution using functional composition:

mss = max º sum* º (flatten º tails* º inits)

– Where inits and tails are defined as follows:
© ASERT 2006-2010

letters = ['a', 'b', 'c', 'd']

assert letters.inits() == [ assert letters.tails() == [
['a'], ['d'],
['a', 'b'], ['c', 'd'],
['a', 'b', 'c'], ['b', 'c', 'd'],
['a', 'b', 'c', 'd'] ['a', 'b', 'c', 'd']
] ]

… Enabling a functional style
• An even more functional style
mss = max º sum* º (flatten º tails* º inits)
def segs = { it.inits()*.tails().sum() }

def solve = { segs(it)*.sum().max() }

def numbers = [31,-41,59,26,-53,58,97,-93,-23,84]
© ASERT 2006-2010

println "Maximum Segment Sum of $numbers is ${solve numbers}"

Notes:
– sum() is one-level flatten in Groovy, flatten() is recursive
– Metaprogramming allowed us to enhance all Lists
List.metaClass {
inits{ (0..<delegate.size()).collect{ delegate[0..it] } }
tails{ delegate.reverse().inits() }
}
Source: http://hamletdarcy.blogspot.com/2008/07/groovy-vs-f-showdown-side-by-side.html

Refactoring recipes with a curry base
• Static: Replace parameter with method
– Refactoring [13]: Chapter 10
• Context
– An object invokes a method, then passes the result as
a parameter for a method. The receiver can also
invoke this method.
© ASERT 2006-2010

• Solution
– Remove the parameter and let the receiver invoke the
method.
• Dynamic solution
– Partial Application: Currying

Replace parameter with method …
class Order {
private int quantity, itemPrice Let's explore the
Order(q, p) {quantity = q; itemPrice = p}
traditional refactoring
double getPrice() {
int basePrice = quantity * itemPrice
int discountLevel
if (quantity > 100) discountLevel = 2
else discountLevel = 1
© ASERT 2006-2010

double finalPrice = discountedPrice(basePrice, discountLevel)
return finalPrice
}

private double discountedPrice(int basePrice, int discountLevel) {
if (discountLevel == 2) return basePrice * 0.8
return basePrice * 0.9
}
}

println new Order(120, 5).price // => 480.0

… Replace parameter with method …
class Order {
private int quantity, itemPrice

double getPrice() {
int discountLevel
if (quantity > 100) discountLevel = 2
else discountLevel = 1
© ASERT 2006-2010

double finalPrice = discountedPrice(basePrice, discountLevel)
return finalPrice
}

private double discountedPrice(int basePrice, int discountLevel) {
if (discountLevel == 2) return basePrice * 0.8
}
}


class Order {

double getPrice() {
double finalPrice = discountedPrice(basePrice)
return finalPrice
}
© ASERT 2006-2010

private double discountedPrice(int basePrice) {
if (getDiscountLevel() == 2) return basePrice * 0.8
}

private int getDiscountLevel() {
if (quantity > 100) return 2
return 1
}
}

class Order {

double getPrice() {
return discountedPrice(getBasePrice())
}

private double discountedPrice(int basePrice) {
© ASERT 2006-2010

if (getDiscountLevel() == 2) return basePrice * 0.8
}

private int getBasePrice() {
quantity * itemPrice
}

return 1
}
}

class Order {

double getPrice() {
return discountedPrice()
}

private double discountedPrice() {
© ASERT 2006-2010

if (getDiscountLevel() == 2) return getBasePrice() * 0.8
return getBasePrice() * 0.9
}

private int getBasePrice() {
}

return 1
}
}

… Replace parameter with method
class Order {

double getPrice() {
if (getDiscountLevel() == 2) return getBasePrice() * 0.8
return getBasePrice() * 0.9
}
© ASERT 2006-2010

private getBasePrice() {
}

private getDiscountLevel() {
Note the now small
return 1 parameter lists
}
}

Some functional style …
class Order {

def discountedPrice = { basePrice, discountLevel ->
discountLevel == 2 ? basePrice * 0.8 : basePrice * 0.9 }

def price = {
© ASERT 2006-2010

def discountLevel = (quantity > 100) ? 2 : 1
discountedPrice(basePrice, discountLevel) }

}
println new Order(120, 5).price() // => 480.0

Traditional refactoring
still applicable if we used
closures rather than methods...

… Some functional style …
class Order {

def basePrice = { quantity * itemPrice }

def discountLevel = { quantity > 100 ? 2 : 1 }

def price = {
© ASERT 2006-2010

discountLevel() == 2 ? basePrice() * 0.8 : basePrice() * 0.9 }

}

... as we see here

… Some functional style …
class Order {



def discountedPrice = { basePrice, discountLevel ->
© ASERT 2006-2010

discountLevel == 2 ? basePrice * 0.8 : basePrice * 0.9 }

def price = {
discountedPrice.curry(basePrice()).curry(discountLevel()).call() }

}

But we can also use currying

… Some functional style
class Order {



def discountedPrice(basePrice, discountLevel) {
© ASERT 2006-2010

discountLevel == 2 ? basePrice * 0.8 : basePrice * 0.9
}

def price = {
this.&discountedPrice.curry(basePrice()).curry(discountLevel()).call()
}

}

We can also use currying with methods

Closure Refactoring …
• Complex code involving closures

// Before refactoring
def phrase = "The quick brown fox jumps over the lazy dog"
def result = phrase.toLowerCase().toList().
findAll{ it in "aeiou".toList() }. // like WHERE ...
© ASERT 2006-2010

groupBy{ it }. // like GROUP BY ...
findAll{ it.value.size() > 1 }. // like HAVING ...
sort{ it.key }.reverse(). // like ORDER BY ...
collect{ "$it.key:${it.value.size()}" }.
join(", ")
println result

… Closure Refactoring …
• Possible Refactoring

// Refactored helper closures
def lowercaseLetters = phrase.toLowerCase()
def vowels = { it in "aeiou".toList() }
def occursMoreThanOnce = { it.value.size() > 1 }
def byReverseKey = { a, b -> b.key <=> a.key }
def self = { it }
© ASERT 2006-2010

def entriesAsPrettyString = { "$it.key:${it.value.size()}" }
def withCommaDelimiter = ", "

// Refactored main closure
println lowercaseLetters.
findAll(vowels).
groupBy(self).
findAll(occursMoreThanOnce).
sort(byReverseKey).
collect(entriesAsPrettyString).
join(withCommaDelimiter)

… Closure Refactoring
# Add group_by to the Array class
class Array
def group_by
group_hash = {}
uniq.each do |e|
group_hash[e] = select { |i| i == e }.size
end
group_hash
end
end

# Before refactoring
phrase = "The quick brown fox jumps over the lazy dog"
© ASERT 2006-2010

puts phrase.downcase.
scan(/[aeiou]/). # like WHERE ...
group_by. # like GROUP BY ...
select { |key, value| value > 1 }. # like HAVING ...
sort.reverse. # like ORDER BY ... DESC
collect{ |key, value| "#{key}:#{value}" }.join(', ')

# Refactored version
lowercase_letters = phrase.downcase
vowels = /[aeiou]/
occurs_more_than_once = lambda { |key,value| value > 1 }
entries_as_pretty_string = lambda { |key, value| "#{key}:#{value}" }

puts lowercase_letters.
scan(vowels).
group_by.
select(&occurs_more_than_once).
sort.reverse.
collect(&entries_as_pretty_string).join(', ')

Unnecessary Complexity Refactoring
• Dynamic Code Creation
– What to look for: Code uses eval,
class_eval or module_eval to build new
code dynamically
– Issues: harder to read, fluid abstractions
are harder to understand, harder to test
© ASERT 2006-2010

and debug
– What to do:
• move string form of eval to block forms or use
define_method
• move method_missing to use class_eval
(example of Replace Dynamic Receptor with
Dynamic Method Definition)
• consider using Move Eval from Run-time to
Parse-time to overcome bottlenecks
Source: Dynamic Code Creation in Chapter 7: Unnecessary Complexity (Refactoring in Ruby)

Topics
• Introduction
• Design patterns
• Refactoring
Polyglot programming
© ASERT 2006-2010

• Other topics
• More Info

Programming Paradigms...
• Named state
(imperative style –
leads to modularity)
vs unnamed state

http://www.info.ucl.ac.be/~pvr/paradigms.html
(functional and logic
style)
• Deterministic vs
© ASERT 2006-2010

observable
nondeterminism
(threads, guards)
• Sequential vs
concurrent
(message passing
and shared state
styles)

Polyglot Programming…
• Groovy calling clojure
@Grab('org.clojure:clojure:1.0.0')
import clojure.lang.Compiler
import clojure.lang.RT

def src = new File('temp.clj')
src.text = '''
© ASERT 2006-2010

(ns groovy)
(defn factorial [n]
(if (< n 2)
1
(* n (factorial (- n 1)))))
'''
src.withReader { reader ->
Compiler.load reader
}
def fac = RT.var('groovy', 'factorial')
println fac.invoke(5)

…Polyglot Programming
• C# calling F#

// F# Code

type FCallback = delegate of int*int -> int;;
type FCallback =
delegate of int * int -> int
© ASERT 2006-2010

let f3 (f:FCallback) a b = f.Invoke(a,b);;
val f3 : FCallback -> int -> int -> int

// C# Code

// method gets converted to the delegate automatically in C#
int a = Module1.f3(Module1.f2, 10, 20);

SOLID Principles

• Single Responsibility Principle
• Open/Closed Principle
• Liskov Substitution Principle
© ASERT 2006-2010

• Interface Segregation Principle
• Dependency Inversion Principle

Open-Closed Principle...
• Fundamental rule to make
your software flexible
– Many other OOP principles, methodologies and
conventions revolve around this principle
• Open-Closed Principle (OCP) states:
• Software entities should be open for
© ASERT 2006-2010

extension, but closed for modification
• References
– Bertrand Meyer, Object Oriented Software
Construction (88, 97)
– Robert C Martin, The Open-Closed Principle
– Craig Larman, Protected Variation: The Importance of
Being Closed
Picture source: http://www.vitalygorn.com

...Open-Closed Principle...
• Following the Rules
– Encapsulation: Make anything that shouldn’t be seen
private
– Polymorphism: Force things to be handled using
abstract classes or interfaces
• When making class hierarchies:
© ASERT 2006-2010

– Make anything that shouldn’t be open final
– Polymorphism: Always follow weaker pre stronger
post (object substitutability in the static world)
• When making changes that might break
existing clients
– Add a new class into the hierarchy
– No compilation of existing code! No breakages!

Dynamic Language Practices

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Dynamic Language Practices

Semelhante a Dynamic Language Practices (20)

Mais de Paul King

Mais de Paul King (18)

Último

Último (20)

Dynamic Language Practices