Java Simulation – Designing Parking Simulation Software

designjavasimulation

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?

Best Answer

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.

reexamining the problem domain

If you look at the problem domain "people having cars": In order to purchase a car you have some sort of contract which transfers ownership from one person to the other, neither the car nor the person change in that process. Your model is completely lacking that.

thought experiment

Assuming there is a married couple, the man owns the car and he is paying the taxes. Now the man dies, his wife inherits the car and will pay the taxes. Yet, your plates will stay the same (at least in my country they will). It is still the same car! You should be able to model that in your domain.

=> Ownership

A car that is not owned by anyone is still a car but nobody will pay taxes for it. In fact, you are not paying taxes for the car but for the privilege of owning a car. So my proposition would be:

public class Person
{
    public string Name { get; set; }

    public string Surname { get; set; }

    public List<Ownership> getOwnerships();

    public List<Vehicle> getVehiclesOwned();
}

public abstract class Vehicle
{
    public string PlateNumber { get; set; }

    public Ownership currentOwnership { get; set; }

}

public class Car : Vehicle {}

public class Motorbike : Vehicle {}

public abstract class Ownership
{
    public Ownership(Vehicle vehicle, Owner owner);

    public Vehicle Vehicle { get;}

    public Owner CurrentOwner { get; set; }

    public abstract bool HasToPay();

    public DateTime LastPaidTime { get; set; }

   //Could model things like payment history or owner history here as well
}

public class CarOwnership : Ownership
{
    public override bool HasToPay()
    {
        return (DateTime.Today - this.LastPaidTime).TotalDays >= 30;
    }
}

public class MotorbikeOwnership : Ownership
{
    public override bool HasToPay()
    {
        return (DateTime.Today - this.LastPaidTime).TotalDays >= 60;
    }
}

public class PublicAdministration
{
    public IEnumerable<Ownership> GetVehiclesThatHaveToPay()
    {
        return this.GetAllOwnerships().Where(HasToPay());
    }

}

This is far from perfect and probably not even remotely correct C# code but I hope you get the idea (and somebody could clean this up). The only downside is that you would probably need a factory or something to create the correct CarOwnership between a Car and a Person

Object-Oriented Design – Handling Large Class Responsibilities

You probably meant to have Environment as a Facade (facade pattern) and not to implement every detail in it.

Break out all functionality into other classes. Imho each of the responsibilities below should be handled by a separate class that the Environment class uses internally.

Keep information about services in the environment,i.e. environment definition (Service is another class)
Start/stop services meeting some criteria
Apply configuration changes to different service and keep list of updated services
Restart services with configuration change
Revert configuration changes at the end of session
Search/Give Service class based on criteria (name etc.)

Those should give you six new classes. It will probably lead to some other classes too so that you for instance can manage configuration from different classes.

Best Answer

Related Solutions

C# – S.O.L.I.D., avoiding anemic domains, dependency injection

reexamining the problem domain

thought experiment

=> Ownership

Object-Oriented Design – Handling Large Class Responsibilities

Related Topic