I believe that it would be the bridge pattern.

The rationale behind the letter/envelope idiom is to allow multiple implementations of an abstract datatype (either over time or in different application domains), but with no change in the client code. This is achieved in C++ by using an abstract base class from which are derived the both the interface (envelope) class, and the implementation (letter) classes. Calls to envelope methods are delegated to the corresponding letter methods.

An example: Suppose you were doing experiments which produced noisy data, and that you wanted to smooth this data to make long-range trends more apparent. However, you might not be sure which smoothing algorithm would work best, and further you would probably want to refine your chosen algorithm over time for greater efficiency. Using the bridge pattern:

public interface Smoothable {
 public double[] smooth (double[] data);
}

public class Envelope {
 private Smoothable impl;
 public Envelope (Smoothable impl) {
  this.impl=impl;
 }
 public double[] smooth(double[] data) {
   return impl.smooth(data);
 }
}

public class Letter implements Smoothable {
 public double[] smooth(double[] data) {
  //do something
  return smoothedData;
 }
}

Actually, the Smoothable interface does not need to be visible to the client, and the signature of the smooth method can be very different in the envelope and letter classes. The bridge pattern allows the client to use the smoothing classes without worrying about changes in the underlying implementation.

Finally, a disclaimer: I don't have Coplien's C++ book, which appears to be the definitive source on the letter/envelope idiom, so my answer may somewhat off the mark.

The Letter/Envelope idiom is, in my opinion, not quite a Bridge Pattern. Let me explain why:

1. The first thing is that the Letter extends the Envelope (in Coplien's view). This implies that the Letter and The Envelope have the same interface, while in the Bridge Pattern the Abstraction and the Implementor don't.

2. The second thing is that while the idiom's intent is to provide just a placeholder, the Bridge Pattern's intent is to decouple an abstraction from it's implementation.

That is why I would say that the Envelope/Letter idiom is much more similar to the Proxy Pattern (in it's smart reference form).

Note: I do not really like the this idiom because the Envelope is aware about it's subclasses(Letter) and that is not a really healthy thing while doing object-oriented related stuff:). That is why I prefer the Proxy Pattern.

Have a nice day,
Tudor

Of course you were not off. I did not mean that (although I appeared pretty rough :-)). All I was saying is that to me the idiom looks more like a Proxy because of the enforcement of the same interface.

Now, I re-read the handle/body pattern and it's intent is indeed to decouple and abstraction from its implementation. But, the envelope/letter seems to me to be a bit different in intent. I don't know, maybe I am wrong.

Best regards,
Tudor.

I'm relatively new to Patterns and find this question about the envelope/letter idiom intresting. Intresting in that the question brings out the point made in the GOF book "Design Patterns Elements of Resusable Object-Oriented Software" that creating a design pattern is difficult. Here in this message string there is one person who has asked a question and four others who have strong opions about the correct answer. Each proclaims doubt about the previous answers correctness.

I can't tell you how much this message has helped. By the way the GOF has envelope/letter idiom as relating to the State pattern p313 near the bottom of the page.

Thanks to all.

It reads:

"Coplien's Envelope-Letter idiom is related to State. Envelope-Letter is a technique for changing an object's class at run-time. The State-pattern is more specific, focusing on how to deal with an object whose behevior depends on state."