views:

44

answers:

1

Im thinking of implementing a parser framework that would utilize a set of interfaces to make it easy to adapt to different types of data formats. I want to create structure around the way my controller object interacts with this parser and have come up with the following simple structure. I was hoping the community could provide any comments or thoughts on what the advantages / disadvantages are of implementing in this manner :

package
{

     public interface IParser
     {   

             function loadAd(adURL:String):void;
             function parseAd():Object;
     }   
}




package
{

     public interface IXMLParser implements IParser
     {   

             function setAdData(adData:XMLNode):void;
     }   
}




package
{

    public interface IJSONParser implements IParser
    {   

            function setAdData(adData:JSON):void;
    }   
}
  1. Are there any ways to expand the features of these interfaces?
  2. Are there any glaring limitations to these interfaces?
  3. Are there disadvantages to using interface inheritance?
+1  A: 

I actually proposed this at the opening session of the XML 2007 conference for JSON and XML.

Both are tree structures, and it is reasonable to expect that they could share an interface. Of course, each has its peculiarities, and you need to decide how you want to handle things like null values, which XML doesn't have, and namespaces, which JSON doesn't have.

But in principle, it could be a decent idea, using some sort of "sniffer" to distinguish the two. You can find the definitions for the start of an XML file here, and of a JSON file here.

Our XML Converters product actually uses this idea to automatically determine the type of EDI being parsed, and then invokes the appropriate parser and repository.

lavinio