To me, it seems the validity check of a car registration number is nothing which belongs “logically to a Car“, as you wrote, because when you only have this number, you don’t have inherently a related car object in scope, and you probably won’t need one for doing the validation. (Of course, it also does not belong logically to a ParkingLot). The registration number is something with a life time which could be independent from other objects.

The validation might verify some national rules about the order of digits and letters. Or, it could ask at the national car registration board which numbers are valid. So it could either be function in a RegistrationNumber object, or one of a RegistrationBoard class. This makes the validation available in any method of the ParkingLot class, as well as in any method of the Car class, or other places of the code, whereever it is required.

Note further that the design of the getCar method, and what it returns, should not depend on where the validation check can be implemented best. The design of the getCar method should depend on its intended usage, on nothing else. I think it is a little bit strange to think of a ParkingLot validating the correctness of a cars registration number by asking at the national registration board, but if in your system such a validation makes sense when that method is called, then do it, utilizing for example the mentioned RegistrationBoard object.

I think there’s some confusion here over whether you’re trying to model a real-world domain, or implement an actual software program.

In reality, most parking lots don’t “know” which car is in what spot, or even if any given car is in the lot at all. (Some places have automated image recognition of license plates, but that’s a separate issue).

In software, depending on what the ParkingLot class is actually supposed to do, the simplest interface is likely addCar(Car c) and removeCar(Car c), this way ParkingLot is free to record a hash map of each Car object and when it entered the lot so that total charges can be computed. In this way, there doesn’t need to be requirement leakage into the Car class that it have a VIN or license plate # field of a given data type.

(A small optimization on this would be to generate a Ticket class whenever addCar is called, that has a unique transaction identifier. Since the ParkingLot is the one that cares about the unique field, it’s appropriate that it provide an interface for generating one, rather than demanding it from a caller).

Its a bad example, why check for valid car registrations at all.

Lets say it credit cards and you want to do a quick lun 10 check before you make a slow api call to the bank.

I would have a separate object for validation of the number. After all you might want several different validation schemes based on the type of card. Or you might expect entry errors on the UI and want to present/log them differently from api failures.

The flexibility to assemble the raw api client and the validation class in various ways is usually better than having both bits of logic encapsulated in the same class.