This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Wed, 2002-07-31 at 22:44, Jason Tishler wrote: > Rob, > > On Wed, Jul 03, 2002 at 08:44:03AM +1000, Robert Collins wrote: > > How does this approach sound: > > Use the Builder pattern to build the in memory representation. Use a > > second Builder pattern to build the on-disk representation. This is > > similar to your original design, but without the encapsulation issues. > > It's an improvement over the memento approach in the same respect, but > > may take a little more effort. > > > > i.e. we feed a stream into a parser that understands the syntax (you > > could review the parser pattern, but I think that is overkill for > > this). That parser uses a builder to generate the in memory database - > > and which other parts of setup can use if they have specific > > requirements (i.e. if foo is not relocatable, they call into the > > builder). Then at the end the in memory database is given a Builder > > and a stream for the builder, and calls into it to save the file. NB: > > the two builders will have the same abstract parent. (say > > "RebaseBuilder" is a parent of "RebaseIniBuilder" and > > "RebaseMemoryBuilder"). > > > > What do you think? > > If I understand the Builder pattern, then I don't think that it is a > good fit for the rebase configuration file design. You suggest that > RebaseIniParser is the Director and RebaseMemoryBuilder is the Builder > above -- this part is congruent with the Builder pattern. > However, you also seem to suggest that RebaseMemoryDatabase is another > Director. Yes. You have two occasions where the data related to rebasing is transformed - disk to memory, and memory to disk. In both cases, the data has an identical structure (not low level like [inisection] vs inisection: + tabs, but rather high level structure: it has files and each file has a datestamp, memory regions and rebase flags.) > I thought that the Builder pattern uses a single Director to > drive multiple Builders. Additionally, now knowledge of the > configuration file syntax is known by both the RebaseIniParser and > RebaseIniBuilder classes which breaks encapsulation. The file layout is known at two places - yes. However: note that serialisation and deserialisation are very different. It's trivial to ensure that one writes in a given format, less trivial to read it. You could address this percieved encapsulation issue by implementing rebaseIniParser within RebaseIniBuilder. The key point is that you *should* be able to (copy and check for errors) a rebase.ini file simply by RebaseIniParser("rebase-old.ini", RebaseIniBuilder("rebase.ini")).process(); Reading into memory then becomes RebaseIniParser("rebase.ini", myRebaseMemoryBuilder).process(); The point of a Builder pattern is to define a language without defining a storage mechanism. Specific serialisations of that language are encapsulated from the object representation. The gang of four example, of a text layout Builder being driven by specific parsers for Tex, RTF, ASCII shows this quite clearly. What they don't address is serialising the resulting laid out text - back to (say) PostScript or PCL. You may need a different language in that example to build a (PostScript or PCL) output, but in our situation we can reuse the same language - that is the Builder interface. Let me list what classes know what: RebaseIniParser: Understands reading the file syntax. May have a flex and or bison toolkit linked into it. Can direct any 'RebaseBuilder'. RebaseMemory: The Singleton. Can direct any 'RebaseBuilder'. RebaseIniBuilder: Understands writing the file syntax. Can be directed. RebaseMemoryBuilder: Can be directed. Understands the in memory structures. > What do you think of my critique of your critique of my critique...? :,) Recursion: See "Recursion". I think you got sidetracked :}. Seriously, at first glance what you raise *is* an encapsulation issue. However: It's only an issue because we are special casing the code: We are choosing to output the exact same format we are inputting. Let me demonstrate: Imagine that you are adding some fields to the ini file format. You need to: Output the new fields. Understand both the old and the new file formats when reading the file. With the model I'm proposing that becomes trivial: * In the v2 parser detect a v1 file and call that parser instead, with the same builder we were given. * Make a v2 parser by copying the v1 parser and changing as needed. (Yes, variations on a them can be done here - a single parser with some magic, or other tweaks). * Change the IniBuilder class to write in the new format. * If needed, extend the Builder interface to support the new functionality. :].
Attachment:
signature.asc
Description: This is a digitally signed message part
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |