I am refactoring Nifty-GUI's internal workings. Trying to make it less inheritance dependent.
To manage all the Elements (Panels, Images, Text and so on) I have quickly and with not much thought introduced a Element class hierarchy as shown in figure 1.
<img src="http://nifty-gui.lessvoid.com/images/remove-inheritance-before.png" alt="figure 1: reasonable (?) class hierachie" border="0" height="128" hspace="2" vspace="2" width="141" />
figure 1: reasonable (?) class hierachie </strong></p>
Well, each Element has an "void abstract render()" method to render itself. This method is overwritten in the subclasses. This is reasonable because the steps you'll need to render an Image are probably different to f.i. a TextElement. You have seen this kind of solution a million times before. So why should this be a bad thing? Alex Miller points in his Blog the drawbacks of the Template Method out (see his very cool entry here: Alex Miller - Pattern I Hate #2: Template Method</a>). And although this is not really a Template Pattern in it's purest form it sure has most of the drawbacks as Alex points out, for instance:</p>
And it is easily possible. I can extract the functionality of "rendering an element" into an Interface. I call this an "ElementRenderer" Interface with only one Method: "render": You can see in figure 2 the removed hierachy and the new ElementRenderer interface I've come up with as well as the first three implementations. <img src="http://nifty-gui.lessvoid.com/images/remove-inheritance-after.png" alt="figure 2: inject some interface is better" border="0" height="128" hspace="2" vspace="2" width="355" /> figure 2: inject some interface is better</strong></p>
There is one drawback however. All state information that an ElementRenderer needs to render an Element have to be somehow public accessible. In my case that was not much of a problem, because the Element already had a Postition on Screen. All other Information is part of the Renderer. For instance to render an Image the filename of the image is part of the ImageRenderer and not of the Element (because it has something to do with the visual representation of the element, so there's no need to "polute" the Element class with that information). I'm pretty happy now :) Reference:
</ul>
I noticed that the only difference my Elements had until now, was the way they rendered themself on the screen. As I am not really a friend of inheritance at all ;) I ask myself: Why not remove the whole Element hierarchy?</p>
public interface ElementRenderer {</pre></p>
/**</pre></p>
* render the element.</pre></p>
* @param w the Element</pre></p>
* @param r the RenderDevice for output.</pre></p>
*/</pre></p>
void render(Element w, RenderDevice r);</pre></p>
}</pre>
Doing it this way, I can remove the whole Element hierarchy. I am left with a single class, the Element class and I can "inject" different behaviour into this class using different "ElementRenderer" implementations. One way to achieve this is "constructor injection" and simply give the Element constructor an additional parameter, the ElementRenderer this Element should use.</p>
public Element(final ElementRenderer newElementRenderer) { ... }</pre>
So implementing the ElementRenderer is easy and I don't need to care about the whole Element hierachy anymore. Furthermore I noticed that at the moment some elements can share the same ElementRenderer. For instance my MenuItems and Text-Elements really use the same TextRenderer implementation!</p>