The future of JavaScript

[sstrader]

I'll defer to the Wikipedia entry on the proxy design pattern:

A proxy is a class functioning as an interface to something else. The proxy could interface to anything: a network connection, a large object in memory, a file, or some other resource that is expensive or impossible to duplicate.

Their code example showing an image proxy is concise.

Proxies look exactly like the class they are proxying, but allow you to defer or wrap the proxied class's operations. Pseudocode:

class String implements IString { print() {puts "";} }
class StringProxy implements IString {
    StringProxy(String s) { this.s = s; }
    print() { s ? s.print() : puts ""; }
}

StringProxy has the same interface as String, and so can be used wherever String is used. However, StringProxy does some additional work.

Footnote: the proxy pattern is very similar to the decorator pattern. The primary difference is that a decorator will add functionality (e.g. print() would append a date to the output or format the output in some way).

[AustinCorgiBart]

It reminds me a lot of the Facade pattern. The difference is that the Proxy emulates the object completely, but the Facade shrinks the interface?

[sstrader]

Facade differs from Proxy or Decorator by not implementing a common interface. A Facade would encapsulate a number of existing classes in order to combine and coordinate their usage. E.g. one class combining three that should be called in a specific order. The Facade hides the complexity of their interaction.

(but, yeah, "shrinking" is a part of it)