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

• Other topics

• More Info

ESDC 2010 - 2

2006-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

– Many of the rules and patterns we have

been taught must be adapted or adjusted;

some no longer apply at all

2006-2

...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

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

2006-2

… 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

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

2006-2

What do I mean by Dynamic Language?

• I prefer a flexible

definition

• One or more of:– Dynamic typing

• Greater polymorphism

– Metaprogramming

• 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

2006-2

… 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.© A

2006-2

Static VS Dynamic

Static vs Dynamic Typing …

• Static: the type of each variable

(or expression) must be known

at compile time

dynamic advocates: like programming

wearing a straight-jacket?

Unnecessary complexity

2006-2

…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

– 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

2006-2

• Dynamic: type information is known only

at runtime

static advocates: like tightrope walking

with no net?

2006-2

• 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

– 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

2006-2

• Strong vs weak typing– Strong: List<Integer> myList

– Weak: Object myList

• Type safety– How is this provided if at all?

• Type inference– Is this supported?

2006-2

…Static and Dynamic Typing…

2006-2

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

Correctness?

2006-2

Typing Approaches…

2006-2

interface Duck {def waddle()def quack()

class DuckImpl implements Duck {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– If your language doesn’t support it natively you

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

2006-2

Source: Rick DeNatale

…Typing Approaches

• Implicit vs Explicit interfaces– Inheritance too restrictive?

– Duck-typing too flexible?

Adapted from Interface-Oriented Design [2]

Shapedraw()

Rectangledraw()

set_sides()

Squaredraw()

set_sides()

Rectangledraw()

set_sides()

Squaredraw()

set_side()

EquilateralTriangledraw()

set_side()

Pistoldraw()

Menuset_sides()

Rectangledraw()

set_sides()

<<interface>>

Shapedraw()

<<interface>>

RegularPolygonset_side()

Squaredraw()

set_side()

EquilateralTriangledraw()

set_side()

2006-2

I tend to use Explicit types

for major boundaries and

implicit types internally.

• MYTH

Removing static typing always leads to

See also Ruby Visitor

Visitor Pattern

without closures

with closures

Visitor Pattern Verdict

apply the visitor pattern to the extent that

its use may not even be apparent:– Express intent more clearly and improves readability

2006-2

Strategy Pattern

2006-2

Source: http://nealford.com/

interface Calc {def execute(n, m)

class CalcByMult implements Calc {def execute(n, m) { n * m }

class CalcByManyAdds implements Calc {def execute(n, m) {def result = 0n.times {

result += m}return result

def sampleData = [[3, 4, 12],[5, -5, -25]

Calc[] multiplicationStrategies = [new CalcByMult(),new CalcByManyAdds()

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

def multiplicationStrategies = [{ n, m -> n * m },{ n, m ->

def total = 0; n.times{ total += m }; total },{ n, m -> ([m] * n).sum() }

def sampleData = [[3, 4, 12],[5, -5, -25]

sampleData.each{ data ->multiplicationStrategies.each{ calc ->

assert data[2] == calc(data[0], data[1])}

Language features instead of Patterns…

2006-2

Strategy Pattern

with interfaces

with closures

Strategy Pattern Verdict

apply the strategy pattern to the extent

that its use may not even be apparent:– Express intent more clearly and improves readability

– Closures open up whole new possibilities for solving

problems

2006-2

Builder Pattern: MarkupBuilder…

• Create new builder

• Call pretended methods

(html, head, ...)

• Arguments are Closures

• Builder code looks very

declarative but is ordinary

Groovy program code and

can contain any kind of

• Builder pattern from the GoF at the syntax-level

• Represents easily any nested tree-structured data

NodeBuilder, DomBuilder,

SwingBuilder, AntBuilder, …

2006-2

import groovy.xml.*def b = new MarkupBuilder()b.html {

head { title 'Hello' }body {ul {

for (count in 1..5) {li "world $count"

} } } }

...Builder Pattern: MarkupBuilder

2006-2

<html><head><title>Hello</title>

</head><body><ul>

<li>world 1</li><li>world 2</li><li>world 3</li><li>world 4</li><li>world 5</li>

</ul></body>

</html>

import groovy.xml.*def b = new MarkupBuilder()b.html {

head { title 'Hello' }body {ul {

for (count in 1..5) {li "world $count"

} } } }

Builder Pattern: SwingBuilderimport java.awt.FlowLayoutbuilder = 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) {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/

2006-2

Builder Pattern: JavaFX Script

Frame {title: "Hello World F3"width: 200content: Label {

text: "Hello World"}visible: true

2006-2

Builder Pattern: Cheri::Swing

# requires JRubyrequire 'rubygems'require 'cheri/swing'include Cheri::Swing

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

}}@frame.show

2006-2

Builder Pattern: AntBuilderdef ant = new AntBuilder()

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

// create a block of Ant using the builder patternant.sequential {

myDir = "target/test/"mkdir(dir: myDir)copy(todir: myDir) {

fileset(dir: "src/test") {include(name: "**/*.groovy")

}}echo("done")

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

2006-2

Builder Pattern Verdict

• The builder pattern in combination with

dynamic languages helps me:– Express intent more clearly and improves readability

– Tests are still important

2006-2

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, agePerson(name, age) {

this.name = namethis.age = age

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

class StaffMemberUsingInheritance extends Person {private salaryStaffMemberUsingInheritance(name, age, salary) {

super(name, age)this.salary = salary

}String toString() {

super.toString() + " and has a salary of $salary"}

2006-2

… 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 delegateprivate salaryStaffMemberUsingDelegation(name, age, salary) {

delegate = new Person(name, age)this.salary = salary

}def haveBirthday() {

delegate.haveBirthday()}String toString() {

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

2006-2

… 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

parameters rather than the traditional positional

parameters shown here (future versions of Ruby may

have this too)

2006-2

… Delegation Pattern …class StaffMemberUsingMOP {

private delegate

private salary

StaffMemberUsingMOP(name, age, salary) {

delegate = new Person(name, age)

this.salary = salary

def invokeMethod(String name, args) {

delegate.invokeMethod name, args

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()

println p2

p3.haveBirthday()

println p3

Tom is 21 years old and has a salary of 1000

Dick is 26 years old and has a salary of 1100

Harry is 31 years old and has a salary of 1200

2006-2

class StaffMemberUsingLibrary {private salaryprivate personStaffMemberUsingLibrary(name, age, salary) {

person = new Person(name, age)this.salary = salarydef delegator = new Delegator(StaffMemberUsingLibrary, person)delegator.delegate haveBirthday

}String toString() {

person.toString() + " and has a salary of $salary"}

… 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

2006-2

QCON 2010 - 60

2006-2

Better Design Patterns: Delegate…

import java.util.Date;

public class Event {private String title;private String url;private Date when;

public String getUrl() {return url;

public void setUrl(String url) {this.url = url;

public String getTitle() {return title;

public void setTitle(String title) {this.title = title;

}// ...

public Date getWhen() {return when;

public void setWhen(Date when) {this.when = when;

public boolean before(Date other) {return when.before(other);

public void setTime(long time) {when.setTime(time);

public long getTime() {return when.getTime();

public boolean after(Date other) {return when.after(other);

}// ...

QCON 2010 - 61

2006-2

…Better Design Patterns: Delegate…

import java.util.Date;

public class Event {private String title;private String url;private Date when;

public String getUrl() {return url;

public void setUrl(String url) {this.url = url;

public String getTitle() {return title;

public void setTitle(String title) {this.title = title;

}// ...

public Date getWhen() {return when;

public void setWhen(Date when) {this.when = when;

public boolean before(Date other) {return when.before(other);

public void setTime(long time) {when.setTime(time);

public long getTime() {return when.getTime();

public boolean after(Date other) {return when.after(other);

}// ...

boilerplate

QCON 2010 - 62

2006-2

…Better Design Patterns: Delegate

class Event {String title, url@Delegate Date when

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)

Delegation Pattern Verdict

• The delegation pattern can be expressed

more succinctly with dynamic languages:– Express intent more clearly and improves readability

– But don’t forget the testing implications

2006-2

Singleton Pattern…• Pattern Intent

– Ensure that only one instance of a class is created

– Provide a global point of access to the object

– Allow multiple instances in the future without affecting a singleton class's clients

• Static language discussion

points

– Need exactly one instance of a class

and a well-known controlled access

• Allows for lazy creation of instance

– More flexible than static class

variables and methods alone

• Permits refinement of operations and

representation through subclassing

– Reduces name space clutter

• Compared to using static approach

– Multi-threading implications

– 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

2006-2

…Singleton Pattern…

• The details quickly get messy …

2006-2

public final class Singleton {private static final class SingletonHolder {

static final Singleton singleton = new Singleton();}private Singleton() {}public static Singleton getInstance() {

return SingletonHolder.singleton;}

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

2006-2

import com.google.inject.*

@ImplementedBy(CalculatorImpl)interface Calculator {

def add(a, b)}

@Singletonclass CalculatorImpl implements Calculator {

private total = 0def 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 = 0def add(a, b) { total++; a + b }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.metaClassRegistryregistry.setMetaClass(Calculator, new CalculatorMetaClass())

2006-2

• But it is easy using meta-programming

class Calculator {def total = 0def add(a, b) { total++; a + b }

def INSTANCE = new Calculator()Calculator.metaClass.constructor = { -> INSTANCE }

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

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

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

2006-2

• Or annotations

2006-2

@Singleton(lazy=true)class X {

def getHello () {"Hello, World!"

println X.instance.hello

• And again with Ruby

class Aardvarkprivate_class_method :new@@instance = newdef Aardvark.instance@@instance

endend

2006-2

class Aardvarkprivate_class_method :newdef Aardvark.instance@@instance = new if not @@instance@@instance

endend

module ThreadSafeSingletondef self.append_features(clazz)require 'thread'clazz.module_eval { private_class_method :new@instance_mutex = Mutex.newdef self.instance@instance_mutex.synchronize {@instance = new if not (@instance)@instance

end Source: http://c2.com/cgi/wiki?RubySingleton

…Singleton Pattern

• Or for Python– Classic class version (pre 2.2)

– Non-classic class version

class Borg:_shared_state = {}def __init__(self):

self.__dict__ = self._shared_state

2006-2

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

# UsagemySingleton1 = 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:– Express intent more clearly and improves readability

– But don’t forgot testing implications

2006-2

Pattern Summary

• Patterns can be replaced by language

features and libraries

• So patterns aren’t important any more!

2006-2

Topics

• Introduction

• Design patterns

Refactoring

• Other topics

• More Info

2006-2

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’– Some refactorings are done differently

2006-2

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

// Before refactoringObject lastReading() {

return readings.lastElement()}

// After refactoringReading lastReading() {

return (Reading) readings.lastElement()}

2006-2

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?– Maybe but not usually

// Traditional Java styleList myIntList = new LinkedList()myIntList.add(new Integer(0))Integer result = (Integer) myIntList.iterator().next()

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

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

2006-2

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]

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"

2006-2

… Enabling a functional style …

• A first attempt at a more functional style:

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

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"

2006-2

… 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:

2006-2

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

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

assert letters.tails() == [['d'],

['c', 'd'],['b', 'c', 'd'],

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

… Enabling a functional style

• An even more functional stylemss = max º sum* º (flatten º tails* º inits)

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() }

2006-2

def segs = { it.inits()*.tails().sum() }

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

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

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

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.

• Solution– Remove the parameter and let the receiver invoke the

method.

• Dynamic solution– Partial Application: Currying

2006-2

Replace parameter with method …

class Order {private int quantity, itemPriceOrder(q, p) {quantity = q; itemPrice = p}

double getPrice() {int basePrice = quantity * itemPriceint discountLevelif (quantity > 100) discountLevel = 2else discountLevel = 1double finalPrice = discountedPrice(basePrice, discountLevel)return finalPrice

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

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

2006-2

Let's explore the

traditional refactoring

… Replace parameter with method …

double getPrice() {int basePrice = quantity * itemPriceint discountLevelif (quantity > 100) discountLevel = 2else discountLevel = 1double finalPrice = discountedPrice(basePrice, discountLevel)return finalPrice

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

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

2006-2

double getPrice() {int basePrice = quantity * itemPricedouble finalPrice = discountedPrice(basePrice)return finalPrice

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

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

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

2006-2

double getPrice() {int basePrice = quantity * itemPricedouble finalPrice = discountedPrice(basePrice)return finalPrice

2006-2

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

private int getBasePrice() {quantity * itemPrice

2006-2

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

2006-2

double getPrice() {return discountedPrice()

private double discountedPrice() {if (getDiscountLevel() == 2) return getBasePrice() * 0.8return getBasePrice() * 0.9

2006-2

double getPrice() {return discountedPrice()

private double discountedPrice() {if (getDiscountLevel() == 2) return getBasePrice() * 0.8return getBasePrice() * 0.9

2006-2

… Replace parameter with method

double getPrice() {if (getDiscountLevel() == 2) return getBasePrice() * 0.8return getBasePrice() * 0.9

private getBasePrice() {quantity * itemPrice

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

2006-2

Note the now small

parameter lists

Some functional style …

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

def price = {int basePrice = quantity * itemPricedef discountLevel = (quantity > 100) ? 2 : 1discountedPrice(basePrice, discountLevel) }

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

2006-2

Traditional refactoring

still applicable if we used

closures rather than methods...

… Some functional style …

def basePrice = { quantity * itemPrice }

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

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

2006-2

... as we see here

… Some functional style …

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

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

2006-2

But we can also use currying

… Some functional style

def discountedPrice(basePrice, discountLevel) {discountLevel == 2 ? basePrice * 0.8 : basePrice * 0.9

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

2006-2

We can also use currying with methods

Closure Refactoring …

• Complex code involving closures

// Before refactoringdef phrase = "The quick brown fox jumps over the lazy dog"def result = phrase.toLowerCase().toList().

findAll{ it in "aeiou".toList() }. // like WHERE ...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

2006-2

… Closure Refactoring …

• Possible Refactoring

// Refactored helper closuresdef 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 }def entriesAsPrettyString = { "$it.key:${it.value.size()}" }def withCommaDelimiter = ", "

// Refactored main closureprintln lowercaseLetters.

findAll(vowels).groupBy(self).findAll(occursMoreThanOnce).sort(byReverseKey).collect(entriesAsPrettyString).join(withCommaDelimiter)

2006-2

… Closure Refactoring

# Add group_by to the Array classclass Arraydef group_bygroup_hash = {}uniq.each do |e|group_hash[e] = select { |i| i == e }.size

endgroup_hash

endend

# Before refactoringphrase = "The quick brown fox jumps over the lazy dog"puts phrase.downcase.scan(/[aeiou]/). # like WHERE ...group_by. # like GROUP BY ...select { |key, value| value > 1 }. # like HAVING ...sort.reverse. # like ORDER BY ... DESCcollect{ |key, value| "#{key}:#{value}" }.join(', ')

# Refactored versionlowercase_letters = phrase.downcasevowels = /[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(', ')

2006-2

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

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

2006-2

Source: Dynamic Code Creation in Chapter 7: Unnecessary Complexity (Refactoring in Ruby)

Topics

• Introduction

• Design patterns

• Refactoring

Polyglot programming

• Other topics

• More Info

2006-2

Programming Paradigms...• Named state

(imperative style –

leads to modularity)

vs unnamed state

(functional and logic

style)

• Deterministic vs

observable

nondeterminism

(threads, guards)

• Sequential vs

concurrent

(message passing

and shared state

styles)

2006-2

w.info

.ucl.ac.b

...Programming Paradigms

2006-2

w.info

.ucl.ac.b

Polyglot Programming…

• Groovy calling clojure

@Grab('org.clojure:clojure:1.0.0')import clojure.lang.Compilerimport clojure.lang.RT

def src = new File('temp.clj')src.text = '''(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)

2006-2

…Polyglot Programming

• C# calling F#

// F# Code

type FCallback = delegate of int*int -> int;;type FCallback =

delegate of int * int -> int

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);

2006-2

Topics

• Introduction

• Design patterns

• Refactoring

SOLID principles

• Other topics

• More Info

2006-2

Source: http://www.lostechies.com/content/pablo_ebook.aspx (Derick Bailey)

SOLID Principles

• Single Responsibility Principle

• Open/Closed Principle

• Liskov Substitution Principle

• Interface Segregation Principle

• Dependency Inversion Principle

2006-2

Source: http://www.lostechies.com/content/pablo_ebook.aspx

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

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

2006-2

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:– 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!

2006-2

Optional

FactoryOptional

Factory

• Part I: If I violate the Open part of OCP in

static languages

– I can’t make the future enhancements I need

• Part II: If I violate the Closed part of OCP

– Client applications using my libraries might

break or require recompilation in the future

2006-2

Extendible

Class A

Class A’

Class A

Class A’

Interface

Class A Class A’

Class A

Class A’

• Part I: Consider Java’s String class– Has methods to convert to upper or

lower case but no swapCase() method?

– Traditionally, consider creating an

EnhancedString class using inheritance?

– I can’t: String is immutable and final

• In OCP terms, it is not open for extension

• Dynamic language solution: open classes

String.metaClass.swapCase = {delegate.collect{ c ->c in 'A'..'Z' ?c.toLowerCase() :c.toUpperCase()

}.join()}assert "Foo".swapCase() == "fOO"

2006-2

#lightopen Stringtype System.String with

member x.swapCase =seq { for letter in x.ToCharArray() do

if (System.Char.IsLower(letter))then yield System.Char.ToUpper(letter)else yield System.Char.ToLower(letter)

}printfn "result: %A" "Foo".swapCase

• Part II: Violating OCP (see [15])

class Square {def side

}class Circle {

def radius}

class AreaCalculator {double area(shape) {

switch (shape) {case Square:

return shape.side * shape.sidecase Circle:

return Math.PI * shape.radius ** 2}

2006-2

• What’s wrong– If we wanted to introduce a Triangle, the

AreaCalculator would need to be recompiled

– If we wanted to change the order the shape

information was displayed, there might be many

changes to make

def shapes = [new Square(side: 3),new Square(side: 2),new Circle(radius: 1.5)

def calc = new AreaCalculator()shapes.sort().each {s ->

println "Area of $s.class.name is ${calc.area(s)}"}

2006-2

• Dynamic shapes– No issue with adding Triangle but sorting is an issue *

class Square {private sidedouble area() { side ** 2 }

}class Circle {

private radiusdouble area() { Math.PI * radius ** 2 }

def shapes = [new Square(side:3),new Square(side:2),new Circle(radius:1.5)

]// unsorteddef prettyPrint = { s ->

println "Area of $s.class.name is ${s.area()}" }shapes.each(prettyPrint)

Area of Square is 9.0

Area of Circle is 7.0685834705770345

Note: Duck-type

polymorphism

instead of

inheritance

polymorphism,

i.e. no base Shape

(abstract) class or

interface.

Hmm… what are

the testing

implications when

I add Triangle?

2006-2

* Our abstractions never designed sorting to be

one of the things open for extension. See [15].

• Dynamic sorting using Closures– As long as we are happy having our sort “code”

within a closure we have complete freedom

– Sometimes representing our abstractions within

classes is appropriate; many times closures will do

// sorted by areadef byArea = { s -> s.area() }shapes.sort(byArea).each(prettyPrint)

Area of Circle is 7.0685834705770345

// sorted circles before squares but otherwise by areadef byClassNameThenArea = { sa, sb ->

sa.class.name == sb.class.name ?sa.area() <=> sb.area() :sa.class.name <=> sb.class.name

}shapes.sort(byClassNameThenArea).each(prettyPrint)

Area of Circle is 7.06858...

Note: Make sure your

closures are testable.

2006-2

• Instead of worrying about– Rigidity

– Fragility

– Immobility

(Because they can be easily gotten

around even if you don’t try to apply OCP)

• We must worry about– Duplication

– Harder refactoring or testing

– Feature interaction

• And of course OCP then leads to ...– Liskov Substitution Principle, Single Responsibility

Principle, Dependency Inversion Principle, ...

2006-2

• “Clean code” [23] states it this way: – Procedural code (i.e. using data structures) makes it

easy to add new functions without changing existing

data structures but when new data structures are

added, all existing procedures may need to change

– OO code makes it easy to add new classes without

changing existing functions but when new functions

are added, all classes must change

• Recommendation?– Choose procedural or OO approach based on

whether anticipated evolution of system involves

functions or data

– Use Visitor (dual dispatch) Pattern if you think both

functions and data might change

2006-2

class Square {double side

class Rectangle {double height, width

class Circle {double radius

class Geometry {def area(shape) {switch (shape) {

case Square: return shape.side ** 2case Rectangle: return shape.height * shape.widthcase Circle: return PI * shape.radius ** 2

2006-2

Can add perimeter() here without shape classes changing but if we

added a Triangle, area(), perimeter() etc. would need to change.

interface Shape {double area()

class Square implements Shape {double sidedouble area() { side ** 2 }

class Rectangle implements Shape {double height, widthdouble area() { height * width }

class Circle implements Shape {double radiusdouble area() { PI * radius ** 2 }

2006-2

If we add perimeter() here, each

shape class must change but we can

add new shapes with no changes

class Square {double sidedouble area() { side ** 2 }

class Rectangle {double height, widthdouble area() { height * width }

class Circle {double radiusdouble area() { PI * radius ** 2 }

2006-2

We can easily add perimeter() here

but for any code requiring the perimeter()

method to exist, we should test that code

with all shapes.

...Open-Closed Principle...• “Clean code” [23] recommendation:

– Choose procedural or OO approach or Visitor

• Agile variation:

– Defer moving to complicated solutions, e.g. Visitor

Pattern, but have in place sufficient tests so that you

can confidently refactor to use one later if needed

• Dynamic language variation:

– You won’t need an explicit visitor (more on this later)

– Duck typing lets you add functions or data without

changing existing classes at the expense of static

type safety

– If you add a function you might need additional tests

for each class associated with that function

– If you add a new class you might need additional

tests for each function associated with that class

2006-2

Topics

• Introduction

• Design patterns

• Refactoring

dynamic language practices

count world

li world

title hello

Technology

patterns and best practices for dynamic osgi applications

fan practices and language learning

grounding language practices preschool - eclkc

dynamic context generation for natural language...

dynamic language for dynamic organization: the role of human...

the dynamic language is not enough

less.the dynamic stylesheet language. ivan leshev

delta dynamic object-oriented programming language

emerging best practices in dynamic pricing

an architecture description language for dynamic service...

dynamic language runtime

dynamic assessment in the language classroom

inclusive language practices

teaching practices in online world language...

the nugram dynamic grammar language

a dynamic programming language for the jvm · clojure a...

intro to python and dynamic languages - columbia … ·...

dynamic logic - online creative best practices 2009 europe

dynamic communication language of leadership

nsf dynamic language infrastructure - neh …...nsf dynamic...