In the last OO design in Haskell thread (and probably in every one preceeding it), it was suggested that having some examples might be a good idea.<br><br>Since most people with existing designs will have some familiarity with Design Patterns, and those are typical building blocks for OO designs, it occured to me that implementing some of them might be a useful excersize. If for nothing other than learning some more Haskell. 
<br><br>Now, some of them are probably bad ideas for implementing in Haskell. There&#39;s a better, or more natural, way than what is suggested by the design pattern. Visitor is probably not a good pattern to follow, for example. On the other hand, others may still be useful, even in a functional language. 
<br><br>So, I&#39;ve been working on a Composite example. I&#39;ve used existential types to have a generic proxy to the base type, rather than a simple algebraic type, since adding new leaves to the algebraic type means modifying the whole type, a violation of the Open-Closed principle (open for extension, closed for modification)
<br><br>The interface of the composite. Two methods, add and draw.<br><br>&gt; class IComponent e where<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; draw ::e -&gt; String<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; add :: (IComponent e&#39;) =&gt; e -&gt; e&#39; -&gt; Component<br><br>
<br>A proxy type which can hold any kind of component, and provides the<br>&#39;virtual&#39; dispatch implementation. That is, it forwards to the add<br>or draw implementation of the instance it is proxying for.<br><br>&gt; data Component = 
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; forall e.(IComponent e) =&gt; Component e<br><br>&gt; componentDraw :: Component -&gt; String<br>&gt; componentDraw (Component c) = draw c<br><br>&gt; componentAdd :: (IComponent e) =&gt; Component -&gt; e -&gt; Component
<br>&gt; componentAdd (Component e) a&nbsp; = Component (add e a)<br><br>&gt; instance IComponent Component where<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; draw = componentDraw<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; add = componentAdd <br><br><br>The Single type, which is the leaf node in this composite, add is a
<br>no-op, except for wrapping the value in a Component. Since there<br>isn&#39;t an implicit down cast from the &#39;derived&#39; Single to the &#39;base&#39;<br>Component.<br><br>&gt; data Leaf = <br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Text String
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; deriving(Show, Eq)<br><br>&gt; leafDraw :: Leaf -&gt; String<br>&gt; leafDraw (Text s) = show s<br><br>&gt; leafAdd :: (IComponent e) =&gt; Leaf -&gt; e -&gt; Component&nbsp; <br>&gt; leafAdd s _&nbsp; = Component s<br>
<br>&gt; instance IComponent Leaf where<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; draw = leafDraw<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; add = leafAdd<br><br><br><br>The Composite type, which holds a list of Components through the<br>composite proxy. I was tempted to make the list a state variable,
<br>so that add could modify rather than produce a new Many, but I<br>wanted to get the basics working.<br><br>&gt; data Composite =<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Many [Component]<br><br>&gt; compositeDraw :: Composite -&gt; String<br>&gt; compositeDraw (Many [])&nbsp; = &quot;()&quot;
<br>&gt; compositeDraw (Many leaves)&nbsp; = &quot;(&quot; ++ (foldr1 (++) $ map draw leaves) ++ &quot;)&quot;<br><br>&gt; compositeAdd :: (IComponent e) =&gt; Composite -&gt; e -&gt; Component&nbsp; <br>&gt; compositeAdd (Many leaves) c = 
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Component $ Many ((Component c) : leaves)<br><br>&gt; instance IComponent Composite where<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; draw = compositeDraw<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; add = compositeAdd<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br><br><br>