Paweł Baczyński wrote:One tip: do not hardcode indices.
James Burefield wrote:I just started to learn Java and I really like it. What does it mean...indices?
Stefan Evans wrote:
So seats
- have a number
- may be first class or economy class
- may be booked or not.
Write a class "Seat" that can encapsulate that information.
Then have your 'two dimensional array' of Seat objects instead of booleans.
No, you have simply kludged something which we all thought was a poor design.James Burefield wrote:I solved my problem. . . .
Campbell Ritchie wrote:
No, you have simply kludged something which we all thought was a poor design.James Burefield wrote:I solved my problem. . . .
Junilu Lacar wrote:I think it's natural to look at an airplane seating chart and, as a programmer, see a "grid" that seems to easily translate to a two-dimensional array. IMO, an array doesn't quite fit the standard nomenclature for seats on a plane though. On all the flights I've ever been on, seat assignments are designated with a row number and a seat letter, with A on the port side, B to the right of A, C to the right of B, and so on to the starboard side. What's more, in first class, some of the letters are not used at all. For example, on a 787, you can have seats 1A, 1B, 1D, 1E, 1K, and 1L and no seats designated as 1C, 1F, 1G, 1H, 1I, or 1J. Other irregularities in the "grid" can be seen around exit rows, galleys, and the narrower portions of the tail section on some planes.
As an exercise, sure, I guess you can pretend that your fictitious plane's seating layout is perfectly symmetrical and seats are designated as row#/seat# but I still think you'd be falling into a trap of letting the visual aspect of the plane's seating layout (the view) influence your internal data structure choice too much. I would much rather separate the way the seats are arranged in a seating layout from the way I identify the seats, whether they are objects in memory or kept in a persistent store like a database or file.
If it were me, I would just have a List<Seat> or Map<Seat>. These seem like they would fit better with the kind of code I wanted to write.
The variables on lines 1-3 would be assigned values somehow, maybe after the user enters information in a form, or a batch of data is processed from an input file.
Lines 6-9 might be the code that books a particular seat for a passenger. Let's say the user opens a browser and goes to a "Seat Selection" page. The user selects a "seat" by clicking on an image that has seatIds associated with it. When a particular area of the seat layout image is clicked, a request with the corresponding seatID is submitted to the program which eventually executes these lines of code to book the seat. Nothing really screams "Use an array!" in this code when I start thinking about how to implement it. However, the seatId definitely looks like it could be a key to a Map or a unique attribute that I can use to find a particular item in a List.
This may be going above the "Beginner Java" level and into more of a design discussion. If all you want to do is learn how to work with arrays, I guess you could go with the Seat[][] structure for now and leave the vagaries of real-world airline booking for another day.
James Burefield wrote:I solved my problem.
James Burefield wrote:This is just an exercise about arrays
Junilu Lacar wrote:
James Burefield wrote:This is just an exercise about arrays
Yes, I realize it is. As far scenarios go though, however, I think your teacher could have given you a better one in which to use an array of booleans. For reasons already stated, the airplane seating chart is just a not good fit. A better fit probably would be something like a game like Battleship or Connect Four. I could see you using an array of boolean with those problems.
Edit: On second thought maybe not so much for those suggestions either. The classic problem where boolean arrays are used is the Sieve of Eratosthenes to find prime numbers. Another that just came to mind is Conway's Game of Life simulation.