Friday, January 31, 2014

"This course surveys the entire length of human history, from the evolution of various human species in the Stone Age up to the political and technological revolutions of the twenty-first century to present a panoramic study on the history of Humankind; following the Cognitive, Agricultural and Scientific Revolutions, and the Unification of Humankind. Its aim was to give a brief but complete overview of the history of Homo sapiens."

It's been the longest course I've finished in Coursera (17 weeks). It has changed my perspective on many different historical processes and human phenomena such as religion, economy or politics. The contents are very critical and sometimes even controversial but I think it's been worth it to be exposed to these ideas in order to reflect on the past and the present of humankind from a different angle.

As it's summarized by InfoQ, he "explains how to distinguish FP hype from reality and to apply key ideas of FP in non-FP languages, separating the good parts of FP from its unnecessary cultural baggage."

"The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it."

The first implementation is written in C++:

I modified the book example to make it shorter. In this case the Duck class has only one configurable behavior: quacking.

This behavior is injected through its constructor but can also be modified afterwards using a setter: changeHowToQuack.

Since C++ is statically typed like Java, we need to create a base type for all the different behaviors or strategies. In this case the QuackBehavior abstract class (this would work as a Java interface).

The Duck class has a field, howToQuack, which is a pointer to an object that implements the QuackBehavior interface. When Duck's quack() method is called, it delegates the quacking responsibility to its howToQuack collaborator.

Using this pattern we've encapsulated the quacking behavior and made it possible to change how the duck quacks without changing its code just by injecting new variants of the behavior. The code respects the Open-Closed Principle for the quack behavior because it's Open to extension (by creating new types of QuackBehavior) and Closed to variation (we don't need to change the Duck class).

This way of implementing the Strategy pattern in C++ or Java has to do with two facts:

They are both statically typed languages.

Functions are not first-class citizens in any of them.

In languages like Ruby or Python we wouldn't need to use an interface like QuackBehavior. We'd just need to make the different behaviors (Quack, Squeak and MuteQuack) have a common interface: quack().

Moreover, since functions are first-class citizens in these languages, we wouldn't even need classes for the different types of behaviors. In this case, functions would suffice, as you can see in this other example of the Strategy pattern in Ruby (much less verbose than the C++ or Java ones):

The Strategy pattern relies on composition. I can't avoid thinking that it's a way to compose behavior that is very similar to what you do when you're using higher-order functions in functional programming.

This last example in Racket has the same functionality as the previous two:

Even though there are no objects here, you can notice some similarities.

It's also applying the Open/Closed principle because it's injecting a behavior as a function parameter, how-to-quack, that has several variations inside a higher-order function, quack, in order to change the function behavior without having to change its code. To get a new behavior, you just need to create a new type of quack function (a different quack behavior) and pass it to quack as a parameter.

Well I hope this makes you see the Strategy pattern from a little bit different perspective.