The representation of interest is here the (presumably) string result obtained from
Someone has to create an instance of the abstract
TextConverter; this is not shown within the diagram you posted in the question.
Some code somewhere chooses between one of the three sub classes to instantiate and then supplies that to the
This might look as follows:
var tx = new TexConverter ();
var rdr = new RTFReader ( tx );
return tx.GetTexText ();
and, in another case,
var cv = new ASCIIConverter ();
var rdr = new RTFReader ( cv );
return cv.GetASCIIText ();
With this additional context, we can see more clearly the separation of construction responsibilities from representation responsibilities, as
ParseRTF is reused unchanged between these two snippets even though each snippet generates a different representation.
Further, if we wanted to, we could create an implementation for
TextConverter that wrapped the other three and created all those representations with one call to
ParseRTF. This would not be as easy to do if these responsibilities were not separated.
It should be pointed out that in this example, the resulting data structures that are constructed do not necessarily have to conform to each other, so,
GetTexText, could, if desired, return a type different from string and different from
GetASCIIText; this would illustrate vastly different representations.