[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
Ludus Design, http://ludusdesign.com/
"First they ignore you. Then they laugh at you.
Then they fight you. Then you win." -- Gandhi