This is actually pretty good. You need to decide on how your readFile() method should return the file data. For a .txt file a common practice is to return a List<String> with one String for each line of the file. The data that you return from processFile() is unclear without further details of the requirements. I presume it will be a Collection of class instances, most likely of classes you'll need to create. Your writeFile() method might possibly use a toString() method or methods from the class(es) you create.
Jay Rex wrote:
you could also use a Stream<String> but it is less obvious how you are going to do it.
Carey Brown wrote:. . . . For a .txt file a . . . a List<String> with one String for each line of the file. . . . .
Knute Snortum wrote:But as cool as that sounds, it would be more usual to see something like this:
Carey Brown wrote:This is actually pretty good.
Jay Rex wrote:read can take something as a parameter. The filename would be ideal. it can return the List<String>.
process can take the returned List<String> as a parameter, and return a processed List<String>.
write would need to take the processed List<String> as a parameter and return the written file?
Without parameters, this becomes a simple method chain, but how do I specify the input and output file names?
Campbell Ritchie wrote:The one way I can think you can chain methods is via a Stream. Even Cay Horstmann's books have Streams as an “advanced” feature, but I think they should be taught early in courses. Another advantage about the Stream is that even a large file with millions of lines doesn't risk overwhelming your memory because only one line is in memory at a time.
Jay Rex wrote:How would I implement this?
read(input.txt) could return a List<String>.
process could accept the List<String> as a parameter.
write would need to accept the processed List<String> and the file name.
The only parameter is the file name, which follows the pseudo code, but how would you implement that?
Dave Tolls wrote:. . . That would (I assume) be a read-line/process-line/write-line (or something along those lines anyway). Which is why you can handle massive files. . . .
Dave Tolls wrote:Method chaining, though it can be done, is not really applicable in this case. The main reason being that the methods can't be called in any order. You need to read the file before processing. So I would argue that allowing such chaining would not reflect how the code has to work.
Carey Brown wrote:So, without the detailed requirements all you've got is an outline of the big picture steps; a good beginning but a long way off from a true design.
Something like this?You are either going to end up with a long method if you have the reading and processing and writing in the same place, or you get awkward code like the above. It would have been even worse before try with resources was introduced.
Dave Tolls wrote:. . . A non-stream method would open input file to get a reader, open output file to get a writer, then process line by line, which would involve reading a line, processing the line, then writing the line.
Campbell Ritchie wrote:Something like this
Thank you. How much of Stream code would be such boilerplate? Let's go back to my earlier example.Two lines of sort of boilerplate at the beginning and four lines of catch, and lines 3 and 12 contain only braces.. Not too bad, particularly if you think you need lines 1‑2 to create the two objects anyway.
Dave Tolls wrote:. . . Pretty much. . . .
Most of it is the boiler plate for opening/closing the files in any case. . . .