This is a self-parking facility
LED signs at the entrance to show how many spots are available.
Above each spot in the garage is a sensor that can sense whether or not there is a vehicle in the spot. If the spot is open, a green light above the spot will be activated. This helps customers find open spots. This also helps the system update the sign at the entrance to show how many open spots there are in the garage.
In "you were asked to..." who is "you" and who is asking to do this? You, the programmer? In what context would you, the programmer, be asked to move a car to a different spot? Why do you need to move it? To me this just sounds like conjecture and imagining that software objects are somehow magically connected to the real objects. This is part of the trap I mentioned and the futile and fruitless thought exercises that come out of it.
Ask yourself, if this were a real system being used by real people in a real parking lot, what scenario would require a change in the parking spot to be reflected in the system? Does it even matter that someone moved a Vehicle from one spot to another? Why does it matter? How does modeling some kind of behavior in the system make it easier to understand the code? How does it help organize the actions that must take place to update the current system state? What effects do these actions have on the user/customer? Do you have any legal right to touch someone's vehicle while it is parked in your facility? What happens when you try to move a car and the alarm goes off?
Sure, this is just an exercise but to make anything you "learn" from it applicable in a real-world scenario, you also have to keep the context of the problem realistic to some extent.
Campbell Ritchie wrote:
Spot onTushar Goel wrote: . . . you don't have to compare true. So instead of . . .
![]()
In fact you can get nasty errors if you use == true or == false and write = instead of == by mistake.
Mike. J. Thompson wrote:Do you just want to know the time it took to solve the puzzle, or are you displaying the stop watch and updating it every second?
sandeeprajsingh tandon wrote:Hi Folks...
Would it be better/worse if each vehicle knew the slot it was parked in and each slot knew the vehicle that is parked on it ie. Vehicle should have a ref to Slot and viceversa ?. That ways, the signature of the unpark could be unpark (uniqueToken, slotNumber). Unpark could simply get the slot on that number and free it up.
Please critique
Darryl Burke wrote:A couple of comments:
-- Suit and rank attributes in a deck of cards are better represented by enums rather than a String and an int.
-- Your class that represents a card (singular) is called Cards (plural). That's misleading. Why not name it Card?
All that matters to the user of the Deck class is that it can supply a Card. How it does that and how the remaining cards are stored is an internal matter of the Deck. So yes, its ArrayList should be private, and Deck could have a public or package-private method Card getCard().
Similar logic would apply to the Player class.
is there an API in ArrayList class that moves(adds to receiver and remove from giver) element across ArrayLists?
Hint: what does the remove(int) method return?