[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Funny situation (was: Re: Serialization et al)



Christian Reiniger wrote:

> > Yes, but can only contain one or the other of directories or file???
> > What, each directory would have two FileSystemEntityContainer, one for
> > the directories it contains and the other for the files it contains? You
> > call that straightforward?
> 
> Yes :+)
> 
> Right now it looks like this:
> 
> DirEntry      // interface all "File System Entities" share
> 
> File  : public DirEntry      // Abstract file representation
> 
> PakFileFile : public File    // File in a PakFile. Concrete.
> 
> Directory : public DirEntry  // Generic directory. Cares about maintaining
>                                 the list of its contents. Contains one
>                                 HashTable<File *> and one
>                                 HashTable<Directory *>
> 
> PakFileDir : public Directory  // Dir in a PakFile. Concrete
> 
> HashTable<>   // "Simple" Container for several files / dirs

Okay, this looks *very* much like what I am thinking about (the
composite pattern), except that Directory would contain DirEntry*.
Internally, this might be two separate (private) hash table for File*
and Directory*, but the interface would be handing out DirEntry*.

Then, you go like this, the interface for directories would have only
AddEntry(DirEntry*) and RemoveEntry(DirEntry*). A directory is a file
(heck, you can even open() them!), this is obvious to me. Thus,
everything is a file. There goes DirEntry (down the drain, with File
becoming the top class). One less class, less methods, I call that
simpler.

-- 
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/
"First they ignore you. Then they laugh at you.
Then they fight you. Then you win." -- Gandhi