Fog Creek Software
Discussion Board




patterns for file import?

is the Abstract Factory design pattern the best pattern for importing different types of files?

what else is there?

thanks!

Patrick
Monday, August 23, 2004

Patterns are a waste of time.  Just write the damn import code and be done with it.


Monday, August 23, 2004

Right, don't bother with trying to come up with a good/maintainable design, just write the goddam spaghetti code and be done with it. Let the next developer with the crap code you write.

Patterns?! We don't need no stinkin' patterns
Monday, August 23, 2004

Let the next developer deal with the crap code you write.

Patterns?! We don't need no stinkin' patterns
Monday, August 23, 2004

BS.  The OP is reading to far into the problem as most people do.  Encapsulate the functionality in a class according the file type and your done.  Maybe make a base class to handle file i/o but it doesn't require anything fancy.  Don't give me this"if you don't use patterns you're writing spagetti code" BS.

If you use patterns, in most situations, you are simply obfuscating the code even further.


Monday, August 23, 2004

Also, if you use patterns, you are obfuscating the problem even further.


Monday, August 23, 2004

Also, I'll be the one getting the work done while you're still mulling over what pattern to use.  I'll be getting the raises and the promotions... Pretty soon I'll be your manager and guess what... You'll be out of a job.


Monday, August 23, 2004

>> just write the goddam spaghetti code and be done with it. Let the next developer with the crap code you write.

What's the matter with you people!!!??? I deal with people! I have G!@^* Damn people skills!!

Tom Smykowski
Monday, August 23, 2004

And also, I'll be the one laughing, with my red stapler in hand, as your "old" place of employment burns to the ground...hehehe...

anon-y-mous cow-ard
Monday, August 23, 2004

> Also, if you use patterns, you are obfuscating the problem even further.

This is so true. But i still use them. I guess I just like to overarchitect stuff.

Tony Chang
Tuesday, August 24, 2004

how can you *not* use a pattern? even 'giant pile of spaghetti' is a pattern, just not always the most appropriate one.

mb
Tuesday, August 24, 2004

A pattern is just a known good solution to a particular problem. If you feel comfortable reinventing the wheel, feel free. Meanwhile I'll use the patterns so I can get done faster, have better confidence in my solution, and go home to the wife and kid. :-)

Oh, and as for the original question: depending on how you're reading the file, the builder pattern might also be a good choice.

Chris Tavares
Tuesday, August 24, 2004

"what else is there?"

There's a gigantic "switch" statement that begins with switch(Filetype)

Hank
Tuesday, August 24, 2004

If the file is XML or a non-trivial grammar, you need libraries to parse the file. Otherwise, it's easy enough to write the code from scratch.

I've found it useful, in Java, to create an iterator that reads one line of a file at a time. Most scripting languages have built-in support for doing that. My iterator constructor has flags to optionally skip blank lines, skip comments (lines start with #) and trim each line (remove leading and trailing spaces).

For delimited files, a tokenizer is useful for separating out the strings between the relevant tokens, such as commas.

This is all rather straightforward, but simple patterns make the code more reliable, maintainable, and faster to write.

Julian
Tuesday, August 24, 2004

Patterns are for making complexity manageable. Start writing the code and REFACTOR to patterns as the need arrises. The really interesting thing about patterns, is not that they are known solutions to problems: They are what good code of tends to converge to over time when complexity increases.

Daren Thomas
Tuesday, August 24, 2004

To the OP:

Yes, IMHO Abstract Factory is indeed a good pattern for importing different types of files. Is it the best? Well that can only be established with a detailed understanding of the requirements. On the face of it though, it should be a good approach.

Excuse my argumentative co-respondents!

Herr Herr
Tuesday, August 24, 2004

Daren - yeah, that's how I tend to work unless it is something whch drops straight into a pattern I already know well fits the problem. In this case I might well switch/case it and then refactor to factory/state machine.


Tuesday, August 24, 2004

I did an image library once.  I think many many people have.

Internally it used a 'native' format, which happened to be a normal uncompressed bitmap as you might expect.

Externally, it could load loads of formats.  Each format had a convertor, which was behind a factory.  The factory could determine a file-type, find the right convertor plugin, and return a native format bitmap.

The key to hiding your importers behind a factory is that you have to have a standardised internal format for these importers to return.

And that format has to be rich-enough to preserve possibly-one-external-format-only if you will be wanting to save back again without being lossy.  (Our internal format had tags for meta data, so if you openned a gif the comment would be saved again when you saved.)

Another design pattern is the The Big Ball of Mud: http://www.laputan.org/mud/mud.html

i like i
Tuesday, August 24, 2004

thanks Chris and a few others. Any others have any meaningful advice regarding a pattern to use for file import?

Patrick
Tuesday, August 24, 2004

use an Anti-Pattern

Yo
Tuesday, August 24, 2004

I've never found a useful pattern for importing. Honestly, the goal of a pattern is to reuse analysis, like a component's goal is to reuse development. Each import processor seems to be unique enough that there hasn't been anything standard behind it, sometimes not even the parser. Or maybe no one has written the "compiler" pattern.

If you find yourself in the position of needing to write lots of import processors, may I recommend you look into YACC/LEX/FLEX/BISON ? Those are parser generators. Required if you build a compiler, and real helpful if you have to write lots of parsers. You describe the language of what you are processing, and feed that to a "generator" that writes code that is mind bogglingly insane.

Somewhere around here, I have the docs to one of these parser generators, and the author stated "I would rather spend 5 years writing a program that writes programs, than write programs." After you stop laughing, it actually starts to make sense.

Peter
Tuesday, August 24, 2004

Always keep patterns and anti-patterns separated with a magnetic field.

Giordi
Tuesday, August 24, 2004

But quadraphasic emissions from patterns and anti-patterns are considered dangerous and will overload the warp core.

"Trip" Tucker
Tuesday, August 24, 2004

*  Recent Topics

*  Fog Creek Home