• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

VehicleType implementations for a Parking Lot ( Single Threaded application )

 
Rancher
Posts: 1090
14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Just recently, I was working on a Parking Lot requirement. I had an abstract VehicleType class as follows.



It's implementations looked as follows.


I had an abstract class that would provide following data to a parking lot.



If the above is the context, have I created singleton implementations the correct way? The comments are rough work. Also should these classes have implemented the Serializable interface? When we are working on an implementation for the first time and we know that the data is not going to be stored in the serialized form ( for the current implementation ), should we still code serial version uuid and have the class implement the Serializable interface? I know a lot if it would depend on the context but would you make the above classes implement the Serializable interface?

Thanks,
Chan.



 
Bartender
Posts: 3648
16
Android Mac OS X Firefox Browser Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Your class initialization for a singleton is fine. But why is a Truck a singleton? Shouldn't it be the parking lot itself?

As for serialization, ideally any objects that "can be transferred over a network" should be serialized. Given your case, if you say serialize your VehicleType then all subclasses (eg Truck, Car, Van, Bus etc) will inherit this serialization. Yet the serialVersionUID should be different for every class.
 
Chan Ag
Rancher
Posts: 1090
14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for your response, K Tsang.

But why is a Truck a singleton? Shouldn't it be the parking lot itself?



Actually the current implementation of the Parking Lot does not need to differentiate amongst the parked vehicles based on say the VIN. Actually there is no Vehicle class, but if I had one, I would have VehicleType as one of the properties. VehicleType are like BUS, CAR, TRUCK, BIGCAR, etc. Each VehicleType has parking per hour charges and number of parking slots it requires. Initially I thought I'd create an enum, but then since the parking lot could support parking of other VehicleType too, I created a VehicleType abstract class.

I created VehicleType implementations as singletons cause I thought there is no need to have more than one object of a particular VehicleType implementation. Do you think I might have made a mistake somewhere?


As for serialization, ideally any objects that "can be transferred over a network" should be serialized. Given your case, if you say serialize your VehicleType then all subclasses (eg Truck, Car, Van, Bus etc) will inherit this serialization. Yet the serialVersionUID should be different for every class.



Yeah, I thought the same. "Objects that can be transferred over a network" is a general guideline, and yes it is THE absolute one criterion. But for this requirement, I do not know. Do you think the VehicleType subclasses should implement the Serailizable interface? I mean are there some general guidelines, we could base this decision on when we're confused? In what cases should a class implement the Serializable interface? What do you think?

Thanks,
Chan.
 
Marshal
Posts: 79178
377
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am with K Tsang.
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. That sort of information should go with the class. Why do you need to implement Comparable and compare the strings alphabetically?
What about subclassing Vehicle? What about an enum?
 
K. Tsang
Bartender
Posts: 3648
16
Android Mac OS X Firefox Browser Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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).

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.

You almost mention each vehicle type can take up more than one parking space, reasonable, yet weird. You not making your parking lot into some battleship playing field are you??

The comparable in the vehicle I think is not necessary. Unless you going to have some logic to determine what vehicle enters the parking lot first. Usually first come first serve.

Once you strip all the excess methods out, you left with an attribute "type" for the VehicleType class. In such cases, it may be more suitable to use a enum to represent the type for your Truck, Car, Van etc classes, depending on how you going to use such classes. But then thinking ahead to maintainability .... Given your ChartProvider usage, an abstract class seems to be better. Yet again, have you consider using an interface for those Truck, Car etc classes? Say have a method "park" and Truck implements that instead?

This seems a lot and may change your design approach.
 
Chan Ag
Rancher
Posts: 1090
14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.





 
Campbell Ritchie
Marshal
Posts: 79178
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You're welcome
 
K. Tsang
Bartender
Posts: 3648
16
Android Mac OS X Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Now I see where you are going with this. For maintainability, I suggest stick with the abstract VehicleType class
 
reply
    Bookmark Topic Watch Topic
  • New Topic