A froggy visitor

Revision as of 10:32, 16 July 2010

Homework excercise for us!

This exercise was introduced during a discussion about this Frogs design example. The question was raised concerning the "exportXML()" method of the frog class:

Is this method good, evil, or the lesser of two evils?

• This method contradicts the Model the real world maxim. A frog does not know about exporting itself and should not be able to.

• If the frog did not know how to export itself then another class would need internal access to achieve this. However, this will break the Encapsulation boundary.

Riel states Model the real world is often violated for keeping related data and behaviour in one place so the current exportXML may very well be the lesser of these two evils.

One solution to this problem would involve

• IExporter -- an interface defining:
  • An export method taking a property name and a property value (overloaded to support int, string, etc differently).
  • BeginSubsection and EndSubsection methods to allow them to export, for instance, their legs. They can BeginSubsection("leg1"), then ask their first leg to export itself, then End(the)Subsection()
• Frog::Export(IExporter) -- a method exporting this frog to whatever format is passed in.
• XmlExporter -- A basic implementation of IExporter which exports to an XML file. Would probably take a filename in the constructor.

In this solution, the XmlExporter does not need to know about a frog, and the frog doesn't need to know Xml -- but it does need to be able to export itself in a relatively generic fashion. I don't think that's too much to ask of a frog.

Advantages of this approach are that it is

• extensible, and
• keeps coupling relatively loose.