Thanks for your responses Campbell and K. Tsang,
Yes I want to improve this design and this is why I'm reworking on it. I want to do it the right way.
There is something very peculiar about singletons when we know there are many different Vehicle objects being driven around. There is also something non‑object‑oriented about a String which records the type of each object.
I have to make sure that VehicleType is a valid type. It's not some "ABC" but it's a "Car" or say a "Truck", or say a "BigCar", or say a "Bus". Sure I can use enums, but what if I may need to add a new VehicleType at a later time, say a VehicleType that requires say 5 parking slots and parking hour charges for this type are say $40 per hour. If VehicleType is a class, anybody can create a VehicleType object, say an "ABC". What if I want to prevent this and also allow new VehicleType to be added in a controlled way?
But now enums sound better to me also. Just how do we ensure that we can add another type when we need to? Or would you say it's just too unlikely a case? And I'm just thinking too much ( going in the wrong direction cause I can have an enum cover every case possible but have my Parking Lot support just a subset of these enum values)?
Yea, implementing Comparable sounds stupid thing to me now. My stupid reason was this. I had to create a report that would print some statistics for each VehicleType, such as how many Vehicles of a particular type entered the Parking Lot this day, How many are currently parked, how many exited, how much parking fee was collected, and so on. This report had VehicleTypes in ascending order of their String type, so I thought if I implemented Comparable, I would be able to convert HashMaps to TreeMaps easily. HashMaps would maintain the counts and I would convert them to TreeMap for creating the report.
Back to the singleton. Suppose I follow your logic of using say Truck as a singleton ... then I expect in your parking lot there will only be one truck or one car or one van... one of every vehicle type we can think of. To me this doesn't make sense.
No actually there can be many.
As per the current requirement -
( A car requires 1 parking slot, a truck requires 2 parking slots. )
Enter operations are specified as follows.
Enter <VehicleType>
A car pays $2 per hour at the time of exiting and a truck pays $3 per hour.
Exit operations are like this.
Exit <VeghicleType> slotnumber
If a VehicleType occupies more than one parking slot, a user may enter any slot number, but the correct vehicle should exit.
Like If I have a Truck parked in slots 4 and 5 and another truck parked in slots 6 and 7, if a user says exit truck 6, 6 and 7 should be freed, not 5 and 6.
ParkingLot should be allowed to support other VehicleTypes in future.
When I'm creating a ParkingLot, I should take care which ParkingSlots are continuous.
Following is a sample output ( the sequence of operations )
run:
Please enter the number of levels :
1
Please enter the number of rows in each level :
2
Please enter the number of columns in each level :
3
Multi Dimensional parking space created with capacity = 6
Parking Lot Created.
report
Cars Entered: 0
Trucks Entered: 0
Cars Exited: 0
Trucks Exited: 0
Parking Cars: 0
Parking Trucks: 0
Spaces available: 6
Fees paid: $0
enter car
Processed // This one would get slot 1 - though I'm not supposed to print this info.
enter car
Processed // This one would get slot 2 - though I'm not supposed to print this info.
enter truck // This one gets 4 and 5 cause 3 and 4 are not continuous.
Processed
enter truck // 3 and 6 are available but a truck cannot be parked.
No Slots Available. Request Ignored.
enter car // gets slot 3.
Processed
report
Cars Entered: 3
Trucks Entered: 1
Cars Exited: 0
Trucks Exited: 0
Parking Cars: 3
Parking Trucks: 1
Spaces available: 1
Fees paid: $0
exit truck 1
Vehicle not found at slot. Request Ignored.
exit truck 5
Processed
report
Cars Entered: 3
Trucks Entered: 1
Cars Exited: 0
Trucks Exited: 1
Parking Cars: 3
Parking Trucks: 0
Spaces available: 3
Fees paid: $3
By the way, Vehicle class is not required cause the operations are based on Parking Slots ( I know I should have specified this, Sorry that I didn't ), not on Vehicle Identification Number. What would you suggest?
Chan for the serialization issue, the ultimate question to ask is: what kind of system is it? Client/server or Web or GUI or something else. If it is a pure client/server system (meaning the server part can be run in a separate VM "and" use the VehicleType class(es) as a transfer object or value object then yes serialize it. Else implement based on your gut feeling (aka optional).
I will work on this - relate this with exiting classes in the src folder and see if I can get an idea. Thanks.
Thanks,
Chan.