4

I've been requested to develop a quite well known problem for a job interview. The Parking Simulation which an example can be found here.

I came up with some ideas for which design pattern should I use and so on, but I got confused when I searched about how other people interpreted that.

This might be a really dumb question, but I need to be sure that I am not the only one who thinks like this.

I've found a lot of people who use a Vehicle Interface which is implemented by classes Car, and Truck (So far, so good). But all of them put the properties of the size occupied by the vehicle and the fee which it has to pay, on those classes as well.

I can understand that. But for me it is not making much sense, since the size is not the actual Vehicle size, but how much parking space it requires. For example (a little no sense but...) you could create another Parking based on motorcycles/bikes size, so the values would differ because the Parking is different, not vehicles themselves.

The same goes for the prices, at least for me, the parking tell the fees, not the vehicles.

But, if the parking do everything the vehicle classes will have nothing to do, and it will not look very cohesive.

Is that clear? Does this make sense or I'm being dumb?

Patrick Bard
  • 337
  • 1
  • 3
  • 10
  • 2
    In some other context you would be right maybe. If this would be about real vehicles and would carry more vehicle information then the parking size and fee should go somewhere else. But: in this very specific context the vehicle classes solely exist for their parking space properties (if I understand this right). Without that information you would not need those classes at all. Maybe just badly named, VehicleParking, CarParking and TruckParking could avoid such confusion. – thorsten müller Apr 04 '15 at 08:52
  • 1
    up-vote. Good thinking! I'm proud for ya'. Seriously. And + to Doc's answer that seems to explain the wrong turn in design ( just a little car parking lingo, there) everyone else is making. Re: your link; everyone should RTFQ. i.e. "...simulate a _car park_". And the follow-on explaination simply does not get into vehicle technical details. No axle count, Gross Weights, dimensions, etc. – radarbob Apr 07 '15 at 00:52
  • Good to know that, I really appreciate it as a young developer. – Patrick Bard Apr 07 '15 at 00:53

1 Answers1

4

I agree fully to you, for the given task, introducing a Vehicle class IMHO does not make much sense. It could make sense in the future, assumed you need to record more information about cars than currently requested, but when someone tells me to write "production ready" code, I would stick as near to the YAGNI principle as possible and would not design any features not requested yet.

To how "other people" might interpret the task: I have seen examples of Vehicle and Car in so many introductory OO examples, especially for introducing the concept of inheritance, that I am pretty sure lots of devs who read the requirement description half-way through are tempted to shoehorn the problem into the Vehicle/Car abstraction they have learned earlier ago.

IMHO that's a form of "programming by conincidence", something which is mentioned in the book "The Pragmatic Programmer" as a kind of anti-pattern.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565