Imagine that you want to proceed any instance or object that realizes a given contract i.e. that implements a given set of specific methods. The classical approach tells you to create a new abstraction (an Interface in Java, a Trait in Scala) that provides all the required method signatures. For instance:
Now, if you want to do the same thing without defining any additional trait, you can use a type definition instead:
/**
* Using a type
*/
type Omnipotent = {
def doThis: String
def doThat: String
}
def doEverything(o : Omnipotent) = {
println(o.doThis)
println(o.doThat)
}
object deity {
def doThis: String = "This is done !!"
def doThat: String = "That is done !!"
def doTheRest: String = "Everything's done!!"
}
doEverything(deity)
Compared to the previous example, the most important difference here is that the deity object doesn't extend anything, but is explicitly of type Omnipotent.
As mentioned in my previous article about the Proxy design pattern, the ability to add features to an existing abstraction without involving an explicit extension of this abstraction is basically the purpose of the Decorator design pattern.
So, this article is simply a recap of the way to implement a Decorator using the technique based on implicit conversion.
In this article we will focus on the Proxy design pattern as defined by the GoF.
In short, the definition of the "Proxy" pattern could be reduced to "something for something". That's why it will be presented here as the Quid Pro Quo pattern, "Quo" meaning the entity that will be controlled/wrapped by the "Quid" entity (i.e. the proxy itself).
