Лучшая практика ООП: Сотрудник. GetCars () по сравнению с Автомобилями. GetByEmployee ()
Учитывая классы Company, Employee, и Car какова предпочтительная практика для методов для получения Автомобилей, связанных с Компанией или Сотрудником?
Employee.GetCars(params...)
Company.GetCars(params...)
Или:
Cars.GetByEmployee(params...)
Cars.GetByCompany(params...)
Первый подход является тем, который я обычно использовал и всегда казался самым интуитивным мне. Но после наблюдения большой кодовой базы, которая использовала второй подход, я должен признать, что это растет на мне. Эти две вещи мне действительно нравится приблизительно второй подход:
- Это группирует все
Carсвязанный код вместе в один файл, делая код более модульным и легче поддержать. - Существует интуитивная логика к наличию любого метода с возвращаемым значением
Car(или больше какList<Car>в этом случае) сгруппированный вCarкласс.
Существует ли лучшая практика, которая покрывает это?
8 ответов
Я бы использовал первый подход в классах сущностей. У этих методов не должно быть никаких параметров, поскольку они возвращают только все ассоциации. Второй подход, который включает некоторую простую бизнес-логику, должен быть помещен во вспомогательный класс или, возможно, CarDAO, если он у вас есть.
Я думаю, что нет единого решения. Это зависит от того, как вы спорите. Если это ответственность автомобилей знать, кому они принадлежат, то я бы использовал второй подход. Но если это ответственность работника - знать, какие машины у него есть, то я бы использовал первый подход.
Однако лично я предпочел бы первый подход, потому что он кажется более простым в реализации.
Лучшего способа не существует. Это зависит от того, что должно делать ваше приложение. Два приложения, использующие одни и те же данные, могут иметь совершенно разные объектные модели, в зависимости от их сценариев использования.
У сотрудника есть автомобиль (или несколько автомобилей, если на то пошло), поэтому каждый сотрудник, естественно, знает, какими автомобилями он пользуется. Но знает ли автомобиль или заботится ли он о том, кто "владеет" им? Я бы сказал, что нет. Он может знать, кто им управляет, но это уже другой вопрос.
Либо машина знает, кто из сотрудников владеет ею (что кажется неправильным, это странные отношения "есть-есть"), либо ей приходится искать всех сотрудников, чтобы найти себя, что еще хуже (нелогично, по-собачьи медленно, все, кроме свободной связи).
Выполните эту задачу с помощью логической обработки Закона Деметры. Очень полезно, верно! хе-хе
Вопрос представлен таким образом, чтобы всегда иметь связь между классами Employee и Car. Если вы можете изменить car.GetByEmployee (...) на car.GetByDriversLicenseNumber (...) (или что-то подобное), тогда вы разделите два класса.
Лучшим подходом было бы уменьшить количество связанных друг с другом объектов. Итак, все зависит от того, как объект следующего уровня в цепочке будет автомобилем.
Я не думаю, что есть один правильный ответ на этот вопрос, все дело в текущей ситуации.
Все дело в отношениях. Может ли один сотрудник иметь более одной машины? (1:N) Никогда не ссылайтесь на сторону 1 со стороны N, так говорил мой учитель. То же самое касается и других вещей. Если у вас 1:1, вы можете сделать и то, и другое. Employee.getCar и Car.getOwner ;-)
Оба подхода кажутся мне немного неправильными. Почему класс Employee должен знать о классе Car? Почему класс Car должен знать о Employee? Ни один из классов не нуждается в другом, чтобы функционировать, поэтому связывать их нет необходимости. Я бы просто хранил где-нибудь словарь, который сопоставлял бы сотрудников с коллекцией автомобилей, а другой словарь сопоставлял бы компании с коллекцией автомобилей.
Neither.
Иметь интерфейс ICarOwner, который реализуется Employee и Company (или их производными), затем создайте класс CarOwnership с атрибутами Car (типа Car или ICar) и Owner (типа ICarOwner).
Когда вам нужно найти владельца автомобиля, вам не нужно заботиться о том, является ли владелец сотрудником или компанией. Вам просто нужно сделать CarOwnerships.GetByOwner(ICarOwner).
Надеюсь, это поможет.