In that case, stop at that stage. Do the reading, put all the lines read into a List<String> and print them. Verify that the right lines are being read in the right order.Sander Hoovenaar wrote:I think that your suggestion is very useful, but my knowledge of Java is only limited. Because of this, I do not fully understand everything you said.
You suggest the following:
The order.txt file is read by a new class, let's call it OrderReader. . . .
Also, if Order is immutable, defensive copies are unnecessary.Stephan van Hulst wrote:. . . The store can prevent this from happening by making so called 'defensive copies', but making Order immutable instead is much more robust, . . .
Campbell Ritchie wrote:In that case, stop at that stage. Do the reading, put all the lines read into a List<String> and print them. Verify that the right lines are being read in the right order.
Then go back and consider the next stage. Yes, it probably will be an Order object. Remember that you can get a Stream<String> from a buffered reader with its lines() methodYou can continue that process to create a List<Order> from the same Stream instead of the List<String>, if you so wish. This is the Collectors class, so you know what to write for its import.
Sander Hoovenaar wrote:The order.txt file is read by a new class, let's call it OrderReader. This reader makes Order objects for each line in the txt-file. These orders will be given a Hash-key...
The time at which the events are executed, I want to save in my Order-objects (see ConfirmTime, ManufacturingTime)
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Stephan van Hulst wrote:
Why is the method public? Why does it return an ArrayList instead of just a List? Don't use File if you don't have to, use java.nio.file.Path instead. You're closing the reader incorrectly. Use try-with-resources. Don't catch NumberFormatException. It's not thrown anywhere. Don't catch Exception. It's too general, catch specific exceptions.
Collectors are useful for making a Stream into a Collection. BufferedReader has a method that does all the heavy lifting of reading lines from a file for you, and it returns them as a Stream.
If all you're going to do with the lines is put them in a List, then you should be using java.nio.file.Files.readAllLines() instead. You can then ignore Collectors.
Stephan van Hulst wrote:Another curious thing: why are you suffixing your variable names with numbers?
Sander Hoovenaar wrote:1. I want to invoke this method in my main(). Would you suggest a different approach?
2. Just read something briefly about the differences. Did only learn about ArrayLists so far. It made sense to me to return an ArrayList, since I started the method by making an ArrayList. Why is it possible to return a different type of List and why bother?
3. What resource/object should close the block then?
At some point during my programming, I suffixed them to ensure that several readers in the same program did not mix up. Later I found that those are local variables ( ) and I distributed the reading methods over other classes.
Sander Hoovenaar wrote:1. This model will be used with txt-files only. That is a given.
2. With the HashKey I wanted to make sure that I execute methods on the right objects. I assume(d) that this one is the best method to do this.
If latitude and longitude are stored in an immutable class, then I can easily request these because these latitudes and longitudes are fixed. I do not have to carry those forward to each separate subsevent.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:Also: I notice you have an orderID. If this is unique, doesn't that also make it a hashcode?
Stephan van Hulst wrote:
Winston Gutkowski wrote:Also: I notice you have an orderID. If this is unique, doesn't that also make it a hashcode?
As long as equality is not based solely on the orderID.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Stephan van Hulst wrote:It's just a safety measure. There's nothing stopping anyone from making two orders that have the same ID but with some of the other properties being different. If these objects are then considered equal based only on their ID, you're setting yourself up for a world of hurt.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Stephan van Hulst wrote:I'm arguing that an ID shouldn't be the only thing to base equality on.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
The moth suit and wings road is much more exciting than taxes. Or this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|