[Clam-devel] PATCH: new File class heirarchy

Xavier Amatriain xavier at create.ucsb.edu
Tue Apr 10 14:28:55 PDT 2007


Thanks Zach, I think your patch points to an underlying question that is
difficult to answer right away:

Do we want the File hierarchy to just depend on the format and not the
content being stored? Or, like you propose, do we want it to depend on
what's being Stored and not the format?

I agree that having the Network class explicitly show the storage format
is bad design but I am not sure having to declare a new file class for
anything you want to store is the way to go. I like the idea of a class
declaring itself XMLStorable (or SDIFStorable...).

As a matter of fact I was talking to David this morning about how the
Acyclic Visitor pattern might help in minimizing dependencies for such a
task: http://www.objectmentor.com/resources/articles/acv.pdf 

On Tue, 2007-04-10 at 13:48 -0700, Zach Welch wrote:
> On Tuesday 10 April 2007 13:31, Zach Welch wrote:
> > > 3. Should there be an EmbeddedNetworkFile?
> >
> > Absolutely.  In fact, I almost think it should be called NetworkFile,
> > because it properly hides the storage mechanism.  I believe it is a poor
> > design that exposes the fact that we store our networks with XML; this new
> > class hides the implmentation details, and I even included my patch for
> > NetworkEditor to re-use it to load/save its networks.
> 
> After sending the above message, I realized that my original patch did not 
> actually include anything to do with EmbeddedNetworkFile. :)  The attached 
> patch shows how the EmbeddedNetworkFile helps begin to abstract the 
> MainWindow away from the direct use of XML.  Sorry for the confusion.
> 
> This patch also helps underscore the ideas that 1) an intermediate NetworkFile 
> base class could be useful (in addition to EmbeddedNetworkFile) and that 2) a 
> NetworkStorageErr exception will be needed to completely hide the XML 
> implementation details.  This patch works great, and it's a clear win from 
> the perspectives of abstraction and encapsulation.  But it's not done.
> 
> Cheers,
> 
> Zach
> _______________________________________________
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
-- 
/*********************************
 *       Xavier Amatriain        *
 *  Associate Director - MATi    *
 *  Research Director - CREATE   *
 *    UCSB, Santa Barbara CA     *
 *      1-(805)- 893 83 52       *
 ********************************/





More information about the clam-devel mailing list