OOP best practice: Employee.GetCars() vs Cars.GetByEmployee()

Question

Given the classes Company, Employee, and Car what is the preferred practice for methods to retrieve Cars associated with Company or Employee?

Employee.GetCars(params...)
Company.GetCars(params...)

Or:

Cars.GetByEmployee(params...)
Cars.GetByCompany(params...)

The first approach is the one I have generally used and always seemed the most intuitive to me. But after seeing a large code-base that used the second approach I have to admit that it's growing on me. The two things I really like about the second approach are:

• It groups all Car related code together into one file, making the code more modular and easier to maintain.
• There is an intuitive logic to having any method with a return value of Car (or more like List<Car> in this case) grouped into the Car class.

Is there a best practice that covers this?

Answer 1

I would use the first approach in the entity classes. There should be no params to these methods as they only return all associations. The second approach which involves some simple business logic should be placed in a helper class or maybe the CarDAO, if you have one.

Answer 2

Its all about releationships. Can one employee have more then one car? (1:N) Never reference the 1 side from the N side, thats what my teacher said. Same for the other things. If you have a 1:1, you can do both. Employee.getCar and Car.getOwner ;-)

Answer 3

I think there isn't a single solution. It depends how you argue. If it is the responsible of the cars to know by whom they are owned, I would used the second approach. But if it is the responsibilty of the employee to know which cars he has, then I would use the first approach.

However I personally would prefer the first approach because it seems to be easier to implemented.

Answer 4

An employee has a car (or some cars, for that matter), so every employee naturally knows which cars (s)he uses. But does the car know or care who "owns" it? I'd say no. It may know who is driving it, but that's a different question.

Either the car does know which employee owns it (which feels wrong, it's a weird has-a relationship), or it has to search all employeed to find itself, which is even worse (illogical, dog slow, everything but loose coupling).

Answer 5

Both approaches seem a little off to me. Why should the Employee class know about the Car class? Why should the Car class know about Employee? Neither class needs the other to function, so coupling them is unnecessary. I would just store a dictionary somewhere that mapped employees to a collection of cars and another that mapped companies to a collection of cars.

Answer 6

There is no best way. It depends on what your application needs to do. Two applications that use the same data can have completely different object models, depending on their use cases.

Answer 7

Run this problem through Law of Demeter logic processing. Very helpful, right! hehe

The question is presented in a way that will always have a coupling between Employee and Car classes. If you can change car.GetByEmployee(...) to car.GetByDriversLicenseNumber(...) (or something similiar) then you would decouple the two classes.

The best approach would be to reduce the number of objects that are coupled toghether. So, it all depends on how the next level object in the chain will the Car.

I don't think there's one right awswer to this question, it all is about the current situation.

Answer 8

Neither.

Have an interface called ICarOwner that is implemented by Employee and Company (or their derivations), then create the class CarOwnership with attributes Car (of type Car or ICar) and Owner (of type ICarOwner).

When you need to need to find car ownership, you don't need to care whether the owner is an employee or a company. You just need to do CarOwnerships.GetByOwner(ICarOwner).

I hope this helps.