Java - Должен ли я использовать поле или класс для решения проблемы следующим образом: - PullRequest
Новая
       17

Java - Должен ли я использовать поле или класс для решения проблемы следующим образом:

2 голосов
/ 23 июня 2010

У меня есть две таблицы в DB

  • FuelStation (fuel_station_id: int (PK), fuel_station_name: varchar, fuel_brand_id: int (FK))
  • FuelBrand (fuel_brand_id: int (PK), fuel_brand_name: varchar)

Как мы видим, обе таблицы связаны между собой.внешний ключ (fuel_brand_id)

Теперь я хочу спроектировать объектную модель, соответствующую вышеупомянутой модели данных, но я не совсем понимаю, какой подход использовать из следующих двух подходов:

  • сделать только один класс FuelStation и хранить марку топлива как String в классе FuelStation.

ИЛИ

  • Сделайте два класса: FuelStation и FuelBrand.А затем свяжите их с отношением Много-к-одному , поскольку одна АЗС будет иметь только одну марку топлива , но одну марку топлива может иметь много заправочных станций .

Q1.Какой подход лучше?

Q2.Каковы плюсы и минусы каждого подхода?

До моих знаний:

Плюсы подхода 2

  • Это сделало нашу объектную модель более гранулированной.

  • В соотв.В соответствии с хорошими принципами проектирования, наша объектная модель должна быть по меньшей мере такой же гранулярной, как и реляционная модель.И подход 2 следует этому принципу

Плюсы подхода 1

  • Нет необходимости создавать отдельный объект для FuelBrand для каждого FuelStation

Ответы [ 3 ]

2 голосов
/ 23 июня 2010
  1. создает только один класс FuelStation и сохраняет марку топлива как String в классе FuelStation.
  2. сделать два класса: FuelStation и FuelBrand. А затем свяжите их с отношением «многие к одному», поскольку на одной АЗС будет иметь только одну марку топлива, а на одной марке топлива может быть много АЗС.

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

  • сколько станций и брендов у вас есть? Если у вас есть огромное количество станций, использующих одну и ту же марку топлива, может быть лучше избежать дублирования, используя второй подход. OTOH, если на практике каждая марка топлива используется только одной станцией (и она не изменится), имеет смысл использовать 1-й подход.
  • возможно / ожидается, что FuelBrand свойства изменятся или будут введены новые свойства? Если это так, то снова лучше использовать второй подход - в противном случае любое изменение в FuelBrand потребует изменения класса FuelStation.
  • Возможно ли, что в будущем на АЗС может появиться несколько марок топлива? Это снова потребует второго подхода.

Как итог, второй подход является более гибким, поэтому я бы предпочел, чтобы, даже если сейчас нет ожидаемых изменений, которые бы явно требовали такого дизайна - при разработке ПО никогда не говорите никогда: -)

1 голос
/ 23 июня 2010

Какой из них лучше, зависит от того, что вы хотите сделать с информацией.

a) Если интересно перечислить все станции, которые поставляют определенную марку, вы также можете выбрать наличие какой-либо карты от названия FuelBrand до набора FuelStations.

b) Если марка топлива обладает или будет иметь какие-либо свойства (цена и т. Д.), Которые вы хотите использовать, лучше выделить из нее класс.

0 голосов
/ 23 июня 2010

Нет необходимости создавать отдельный объект для FuelBrand для каждой FuelStation

В любом подходе одинаковое количество объектов - у вас либо N объектов FuelBrand, либо N строковых объектов, где N - это количество брендов или количество станций, в зависимости от того, используете ли вы объекты повторно или нет. Так что этот аргумент является правдоподобным.

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

...