ООП лучшая практика: Employee.GetCars () против Cars.GetByEmployee ()

Question

Учитывая классы Company, Employee и Car, какова предпочтительная практика для методов поиска автомобилей, связанных с компанией или сотрудником?

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

Или:

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

Первый подход - тот, который я обычно использовал и всегда казался мне наиболее интуитивным.Но увидев большую кодовую базу, которая использовала второй подход, я должен признать, что он растет на мне.Две вещи, которые мне действительно нравятся во втором подходе:

• Он объединяет весь связанный с Car код в один файл, делая код более модульным и простым в обслуживании.
• Интуитивно понятная логика заключается в том, чтобы любой метод с возвращаемым значением Car (или более похожим на List<Car> в данном случае) был сгруппирован в класс Car.что покрывает это?

Answer 1

Я бы использовал первый подход в классах сущностей.В этих методах не должно быть параметров, поскольку они возвращают только все ассоциации.Второй подход, который включает в себя некоторую простую бизнес-логику, должен быть помещен во вспомогательный класс или, возможно, в CarDAO, если он у вас есть.

Answer 2

Оба подхода кажутся мне немного странными.Почему класс Employee должен знать о классе Car?Почему класс Car должен знать о Employee?Ни одному классу не нужен другой для работы, поэтому связывать их не нужно.Я бы просто хранил где-то словарь, в котором сотрудники сопоставлялись бы с коллекцией автомобилей, а другой - с компаниями, которые отображали коллекцию автомобилей.

Answer 3

Сотрудник имеет машину (или несколько машин, если на то пошло), поэтому каждый сотрудник, естественно, знает, какие машины он использует.Но машина знает или заботится, кто "владеет" этим?Я бы сказал нет.Может быть, он знает, кто за рулем, но это другой вопрос.

Либо машина знает, кто из сотрудников владеет ею (что кажется неправильным, странные отношения), либо она должна искать всех занятыхнайти себя, что еще хуже (нелогично, собака медленная, все, кроме слабой связи).

Answer 4

Я думаю, что нет единого решения. Это зависит от того, как вы спорите. Если ответственность за то, кому они принадлежат, лежит на автомобилях, я бы использовал второй подход. Но если работник обязан знать, какие у него машины, то я бы использовал первый подход.

Однако я лично предпочел бы первый подход, потому что, кажется, его легче реализовать.

Answer 5

Запустите эту проблему с помощью логической обработки закона Деметры.Очень полезно, верно!хе-хе

Вопрос представлен таким образом, чтобы всегда иметь связь между классами сотрудников и автомобилей.Если вы можете изменить car.GetByEmployee(...) на car.GetByDriversLicenseNumber(...) (или что-то похожее), то вы бы разъединили два класса.

Наилучшим подходом было бы уменьшение количества объектов, связанных друг с другом.Итак, все зависит от того, каким следующим объектом уровня в цепочке станет автомобиль.

Я не думаю, что есть один правильный ответ на этот вопрос, все дело в текущей ситуации.

Answer 6

Нет лучшего пути. Это зависит от того, что нужно сделать вашему приложению. Два приложения, использующие одни и те же данные, могут иметь совершенно разные объектные модели в зависимости от их вариантов использования.

Answer 7

Ни то, ни другое.

Имейте интерфейс с именем ICarOwner, который реализуется Employee и Company (или их производными), затем создайте класс CarOwnership с атрибутами Car (типаCar или ICar) и Owner (типа ICarOwner).

Если вам нужно найти собственника автомобиля, вам не нужно заботиться о том, является ли владелец сотрудником иликомпания.Вам просто нужно сделать CarOwnerships.GetByOwner(ICarOwner).

Надеюсь, это поможет.

Answer 8

Все дело в выпуске.Может ли один сотрудник иметь более одной машины?(1: N) Никогда не упоминайте 1 сторону с N стороны, так сказал мой учитель.То же самое для других вещей.Если у вас есть 1: 1, вы можете сделать оба.Employee.getCar и Car.getOwner; -)