Advertisement
Guest User

Feedback 2.1.16

a guest
Oct 25th, 2016
67
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 2.72 KB | None | 0 0
  1. Feedback without knowing the thoughts behind the work is hard to give. I hope there will be no major misunderstandings.
  2.  
  3. Classes
  4. ------------
  5.  
  6. All seem quite relevant, what can I say, I had almost the same under different names.
  7.  
  8. Customer being an abstract class is neat, but then why is it shown in the event table? Even if B2B and B2C had the exact same pattern.
  9.  
  10. I see you also plan to handle payments in the system. It was my impression that this was a bit out of scope, but no doubt it would make sense to do. I fail to see the importance of a distinction between Cash and Dankort, however, but then again it is missing in the event table. Same goes for Invoice and Check.
  11.  
  12. Events
  13. ------------
  14.  
  15. Your pattern of New Reservation -> Cancel/Pickup -> Return is very neat.
  16.  
  17. Events mostly allright, though I don't understand why it is important for the system to be able to do credit checks. You will notice in the Event Table that it links only to one class, and I don't think such things are generally automated.
  18.  
  19. Event Table
  20. ------------
  21.  
  22. Looking over it, one can see that it actually has a fine distribution of links. The exception being that Car is attached to everything, but I think that the consensus is that this is mostly unavoidable. (Only thing one can argue, like he did in the lecture, is that Car should not be part of reservations, but only the fact that one is available in the price group. I wouldn't say that'd be objectively better though.)
  23.  
  24. I would like to know why Montly Payment is only linked to New Reservation. If nothing else, what if the reservation is cancelled?
  25.  
  26. The opposite goes for Deposit Difference; Did you mean for it to be at Pickup instead?
  27.  
  28. Does the Deposit class not care that the car is returned?
  29.  
  30. Is Reservation still relevant at Car Return, Repair Car, and Send Reciept? Perhaps the class' purpose is being stretched, or perhaps it has been given a wrong name.
  31.  
  32. Does the Station not care that a Car of its has been sold?
  33.  
  34. Structure
  35. ------------
  36.  
  37. So each station is made up of a series of Reservations, which in turn are from the one class to rule them all.
  38.  
  39. Each Reservation object is made up of information about the customer, the payment-type, deposit difference and the desired car. The Reservation will then have different states(not shown) depending on whether the car has just been reserved, picked up or even returned but not paid for.
  40.  
  41. This is a bit of a convoluted setup, and I think one would do well to rethink it before trying to implement such a system. Both for reasons of understanding but also for technical reasons. What is the program to do if it wishes to know which cars are available? Iterate through reservations and subtract the resulting list of cars in use from the full inventory?
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement